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CHAPTER  11 

Packet  Format  Standard 


11.1  General 

A  large  number  of  unique  and  proprietary  data  structures  has  been  developed  for  specific 
data  recording  applications  that  required  unique  decoding  software  programs.  The  activities  of 
writing  unique  decoding  software,  checking  the  software  for  accuracy,  and  decoding  the  data 
formats  are  extremely  time-consuming  and  costly. 

Specifically,  this  packet  format  standard  shall  be  usable  with  multiplexing  of  both 
synchronous  and  asynchronous  digital  inputs  such  as  pulse  code  modulation  (PCM);  Military 
Standard  (MIL-STD)  1553  data  bus,  time,  analog,  video;  Aeronautical  Radio,  Inc.  (ARINC)  429; 
discrete;  and  Universal  Asynchronous  Receiver  and  Transmitter  (UART)  containing 
Recommended  Standard  (RS)-232/422/485  communication  data.  This  packet  standard  will 
allow  use  of  a  common  set  of  data  interpretation  libraries  to  reduce  the  cost  of  producing  data 
analysis  systems. 


NOTE 

Within  this  standard,  where  text,  figures,  or  tables  are 

used  to  provide  descriptions,  meaning,  and/or 

r 

explanations,  the  text  shall  take  precedence  over  figures 

and  tables. 

The  data  format  structures  (packet  header,  secondary  packet  header,  channel-specific  data 
word  [CSDW],  intra-packet  data  header  [IPDH],  and  packet  trailer)  described  in  Section  11.2  are 
defined  to  have  the  following  bit  and  byte  orientation.  The  least  significant  byte  shall  be 
transmitted  first;  the  least  significant  bit  (lsb)  of  each  byte  shall  be  transmitted  first,  with  most 
significant  bit  (msb)  transmitted  last;  and  data  is  read  from  the  lowest  logical  address  first.  This 
ordering  is  commonly  referred  to  as  “Little  Endian.”  The  packet  data  shall  remain  in  its  native 
byte  order  format. 

11.2  Data  Format  Definitions 

11.2.1  Common  Packet  Elements 

Data  shall  have  three  required  parts:  a  packet  header,  a  packet  body,  and  a  packet  trailer, 
and  an  optional  part  if  enabled,  a  packet  secondary  header.  A  packet  will  always  conform  to  the 
structure  outlined  in  Figure  11-1. 

a.  A  packet  has  the  basic  structure  shown  in  Table  11-1.  Note  that  the  width  of  the  structure 
is  not  related  to  any  number  of  bytes  or  bits.  This  table  is  merely  to  represent  relative 
packet  elements  and  their  placement  within  the  packet.  See  Table  11-2  for  a  diagram  of 
the  generic  packet  format.  This  table  does  not  depict  the  bit  lengths  of  each  field.  Word 
sizes  of  8  bits,  16  bits,  and  32  bits  are  used  depending  on  the  data  type. 

To  further  clarify  the  packet  layout,  Table  11-2  shows  the  generic  packet  in  a  32-bit, 
little-endian  format,  and  assumes  16-bit  data  words  and  data  checksum. 
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Packet 

Header 


Optional 

Packet 

Secondary 

Header 


Packet  Body 


Packet  Trailer 


S 


% 


v. 


Packet  Sync  Pattern 


Channel  ID 


Packet  Length 


1 


Data  Length 


Data  Type  Version 
Sequence  Number 


Bit  7:  Indicates 
the  existence  of 
the  optional 
packet 
secondary 
header. 


Bit  6:  Indicates 
the  intra-packet 
time  stamp  time 
source. 


Bits  3-2:  Indicate 
the  packet 
secondary 
header  time 
format. 


Bits  1-0:  Indicate 
the  data 
checksum 
existence. 


Intra-Packet  Time  Stamp 
(Least  Significant  Long  Word) 

Intra-Packet  Time  Stamp 
(Most  Significant  Long  Word) 

Intra-Packet  Data  Header 

Filler- 


Data  Checksum 
(8  Bit,  16  Bit,  32  Bit,  or  None) 


If  00,  No  Data  Checksum  Present. 

If  01 ,  8-Bit  Checksum  -  If  1 0,  1 6-Bit  Checksum  -  If  1 1 , 32-Bit  Checksum 


□J 


Figure  11-1.  Overall  Packet  Structure 


Table  11-1.  General  Packet  Structure 

PACKET  SYNC  PATTERN 

Packet  Header 

CHANNEL  ID 

PACKET  LENGTH 

DATA  LENGTH 

DATA  TYPE  VERSION 

SEQUENCE  NUMBER 

PACKET  FLAGS 

DATA  TYPE 

RELATIVE  TIME  COUNTER 

HEADER  CHECKSUM 

TIME 

Packet  Secondary 
Header  (Optional) 

RESERVED 
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SECONDARY  HEADER  CHECKSUM 

CHANNEL-SPECIFIC  DATA 

Packet  Body 

INTRA-PACKET  TIME  STAMP  1 

INTRA-PACKET  DATA  HEADER  1 

DATA  1 

INTRA-PACKET  TIME  STAMP  N 

INTRA-PACKET  DATA  HEADER  N 

DATAn 

DATA  CHECKSUM 

Packet  Trailer 
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DATA  CHECKSUM 

Depending  on  the  data  type,  the  size  of  the  data  checksum  can  contain  32  bits,  16  bits,  8 
bits,  or  the  checksum  can  be  entirely  left  out.  For  a  32-bit  data  checksum,  the  packet 
trailer  would  be  as  shown  in  Figure  11-2. 
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Figure  1 1-2.  Packet  Trailer  for  32-Bit  Data  Checksum 


b.  For  an  8-bit  data  checksum,  the  packet  trailer  would  be  as  shown  in  Figure  11-3. 
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Figure  11-3. 

Packet  Trailer 

’or  8-Bit  Data  Checksum 

c.  The  size  of  a  single  packet  may  be  a  maximum  of  524,288  (219)  bytes  as  shown  in  Table 
11-3.  This  includes  the  packet  header,  packet  body,  packet  trailer,  and  optional  packet 
secondary  header  if  enabled.  The  only  exception  to  the  packet  size  limit  is  the  Computer- 
Generated  Data  Packet,  Format  1  setup  record,  which  may  be  a  maximum  of  134,217,728 
(227)  bytes.  Any  packet  that  requires  more  than  524,288  bytes  may  generate  multiple 
packets  by  utilizing  the  packet  sequence  counter.  Some  packet  types  allow  a  single  data 
set  to  span  multiple  packets  if  the  data  set  size  or  time  does  not  fall  under  packet 
maximums.  The  specific  mechanism  allowing  packet  data  spanning  for  each  data  type  is 
described  within  that  data  type’s  section. 


Table  11-3.  Packet  Requirements 

Packet  Type 

Required 

Maximum  Packet  Size 

Computer-Generated  Data  Packet,  Format  1 
Setup  Record 

Yes 

134,217,728  bytes 

Time  Data  Packet 

Yes 

524,288  bytes 

All  other  data  type  packets  with  the  exception 
of  Computer-Generated  Data  Packet,  Format 

1  setup  record,  time  data  packets,  and 
Computer-Generated  Data  Packet,  Format  3 
recording  index  (root  index) 

No 

524,288  bytes 

Computer-Generated  Data  Packet,  Format  3 
recording  index  (root  index) 

Yes,  if  recording 
events  are  enabled. 
No,  if  recording 
events  are  disabled. 

524,288  bytes 
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d.  (Reserved) 

e.  All  packets  that  are  generated  shall  contain  data.  Filler  only,  idle  (as  defined  by  medium 
or  interface)  only,  or  empty  packets  shall  not  be  allowed. 

f.  All  reserved  bit  fields  in  packet  headers  or  CSDWs  shall  be  set  to  zero  (0x0). 

g.  (Reserved) 

h.  Once  version  bits  and  packet  structure  bits  have  been  used  to  indicate  a  value  or  setting 
for  each  data  type  and  its  associated  channel,  they  shall  not  change  for  that  data  type  and 
its  associated  channel  within  the  operational  session  (e.g.,  recording). 


11.2.1.1  Packet  Header 

The  length  of  the  packet  header  is  fixed  at  24  bytes  (192  bits).  The  packet  header  is 
mandatory  and  shall  consist  of  ten  fields,  positioned  contiguously  as  shown  in  Table  11-2  and 
defined  below. 


a.  Packet  Sync  Pattern.  These  2  bytes  contain  a  static  sync  value  for  every  packet.  The 
packet  sync  pattern  value  shall  be  0xEB25. 

b.  Channel  ID.  These  2  bytes  contain  a  value  representing  the  packet  channel  ID.  All 
channels  in  a  system  must  have  a  unique  channel  ID  for  each  data  source. 

(1)  Multiplexer  Source  ID.  In  a  distributed  multiplexer  system,  a  multiplexer  source  ID 
is  used  to  discern  each  multiplexer  in  the  system.  The  setup  record  shall  contain  a 
“Number  of  Source  Bits”  recorder  attribute  (R-x\NSB)  to  specify  the  number  of 
msbs  (from  the  channel  ID)  that  distinguish  the  multiplexer  source  ID.  The 
remaining  lsbs  of  the  channel  ID  field  shall  be  the  channel  ID  for  each  data  source 
acquired  by  the  multiplexer. 

(2)  Reserved  Channel  ID.  Channel  ID  0x0000  is  reserved,  and  as  of  106-17  is  used  to 
insert  only  the  Computer-Generated  Data  Packet,  Format  1  setup  record(s)  or  the 
Computer-Generated  Data  Packet,  Format  4  Streaming  Configuration  records  into 
the  composite  data  stream. 

(3)  Available  Channel  IDs.  All  values  not  comprising  the  reserved  channel  ID  are 
available.  As  of  106-13,  when  Computer-Generated  Data  Packet,  Formats  0,  2,  and 
3  reside  in  a  channel  with  ID  0x000 1-OxFFFF,  only  one  packet  type  shall  exist  per 
channel  ID. 

c.  Packet  Length.  These  4  bytes  contain  a  value  representing  the  length  of  the  entire  packet. 
The  value  shall  be  in  bytes  and  is  always  a  multiple  of  four  (bit  1  and  bit  0  shall  always 
be  zero).  This  packet  length  includes  the  packet  header,  packet  secondary  header  (if 
enabled),  channel-specific  data,  intra-packet  headers  (IPHs),  data,  filler,  and  data 
checksum. 

d.  Data  Length.  These  4  bytes  contain  a  value  representing  the  valid  data  length  within  the 
packet.  This  value  shall  be  represented  in  bytes.  Valid  data  length  includes  channel- 
specific  data,  IPDHs,  intra-packet  time  stamp(s)  (IPTS),  and  data  but  does  not  include 
packet  trailer  filler  and  data  checksum. 
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e.  Data  Type  Version.  This  byte  contains  a  value  at  or  below  the  release  version  of  the 
standard  applied  to  the  data  types  in  Table  11-4.  The  value  shall  be  represented  by  the 
following  bit  patterns. 


0x00  =  Reserved 

0x01  =  Initial  Release  (Range  Commanders  Council  [RCC]  106-04) 

0x02  =  RCC  106-05 

0x03  =  RCC  106-07 

0x04  =  RCC  106-09 

0x05  =  RCC  106-11 

0x06  =  RCC  106-13 

0x07  =  RCC  106-15 

0x08  =  RCC  106-17 

0x09  through  OxFF  =  Reserved 


Note:  References  to  RCC  106-04  through  RCC  106-15  refer  to  Chapter  10,  while  RCC 
106-17  onward  refer  to  Chapter  11. 


Table  11-4.  Data  Type  Names  and  Descriptions 

Packet 

Header 

Value 

Data  Type  Name 

Data  Type  Description 

Current 
Data  Type 
Version 

0x00 

Computer-Generated  Data,  Format  0 

User-Defined 

0x06 

0x01 

Computer-Generated  Data,  Format  1 

Setup  Record 

0x08 

0x02 

Computer-Generated  Data,  Format  2 

Recording  Events 

0x06 

0x03 

Computer-Generated  Data,  Format  3 

Recording  Index 

0x06 

0x04 

Computer-Generated  Data,  Format  4 

Streaming  Configuration 
Records 

0x08 

0x05  -  0x07 

Computer-Generated  Data,  Format  5- 
Format  7 

Reserved  for  future  use 

0x06 

0x08 

PCM  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x09 

PCM  Data,  Format  1 

Chapter  4  or  8 

0x06 

OxOA  -  OxOF 

PCM  Data,  Format  2  -  Format  7 

Reserved  for  future  use 

0x06 

0x10 

Time  Data,  Format  0 

Reserved  for  future  use 

0x06 

J3xll 

Time  Data,  Format  1 

RCC/Global  Positioning 
System  (GPS)/Relative 
Time  Counter  (RTC) 

0x06 

0x12 

Time  Data,  Format  2 

Network  Time 

0x08 

0x13-0x17 

Time  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x18 

MIL-STD-1553  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x19 

MIL-STD-1553  Data,  Format  1 

MIL-STD-1553B  Data 

0x06 

OxlA 

MIL-STD-1553  Data,  Format  2 

16PP194  Bus 

0x06 

OxlB-OxlF 

MIL-STD-1553  Data,  Format  3- 
Format  7 

Reserved  for  future  use 

0x06 

0x20 

Analog  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x21 

Analog  Data,  Format  1 

Analog  Data 

0x06 
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Table  11-4.  Data  Type  Names  and  Descriptions 

Packet 

Header 

Value 

Data  Type  Name 

Data  Type  Description 

Current 
Data  Type 
Version 

0x22-0x27 

Analog  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x28 

Discrete  Data,  Format  0 

Reserved  for  future  use 

0x06 

0x29 

Discrete  Data,  Format  1 

Discrete  Data 

0x06 

0x2A-0x2F 

Discrete  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x30 

Message  Data,  Format  0 

Generic  Message  Data 

0x06 

0x31-0x37 

Message  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x38 

ARINC-429  Data,  Format  0 

ARINC-429  Data 

0x06 

0x39-  0x3F 

ARINC-429  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x40 

Video  Data,  Format  0 

MPEG-2/H.264  Video 

0x06 

0x41 

Video  Data,  Format  1 

ISO  13818-1  MPEG-2 

0x06 

0x42 

Video  Data,  Format  2 

ISO  14496-10  MPEG-4 
Part  10  A  VC/ITU  H.264 

0x06 

0x43 

Video  Data,  Format  3 

MJPEG 

0x07 

0x44 

Video  Data,  Format  4 

M  JPEG- 2000 

0x07 

0x45-0x47 

Video  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x48 

Image  Data,  Format  0 

Image  Data 

0x06 

0x49 

Image  Data,  Format  1 

Still  Imagery 

0x06 

0x4A- 

Image  Data,  Format  2 

Dynamic  Imagery 

0x06 

0x4B-0x4F 

Image  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x50 

UART  Data,  Format  0 

UART  Data 

0x06 

0x51-0x57 

UART  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x58 

IEEE  1394  Data,  Format  0 

IEEE  1394  Transaction 

0x06 

0x59 

IEEE  1394  Data,  Format  1 

IEEE  1394  Physical 

Layer 

0x06 

Ox5A-Ox5F 

IEEE  1394  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x60 

Parallel  Data,  Format  0 

Parallel  Data 

0x06 

0x61-0x67 

Parallel  Data,  Format  1 -Format  7 

Reserved  for  future  use 

0x06 

0x68 

Ethernet  Data,  Format  0 

Ethernet  Data 

0x07 

0x69 

Ethernet  Data,  Format  1 

Ethernet  UDP  Payload 

0x06 

0x6A-0x6F 

Ethernet  Data,  Format  2-Format  7 

Reserved  for  future  use 

0x06 

0x70 

TSPPCTS  Data,  Format  0 

GPS  NMEA-RTCM 

0x06 

0x71 

TSPECTS  Data,  Format  1 

EAG  ACMI 

0x06 

0x72 

TSPPCTS  Data,  Format  2 

ACTTS 

0x06 

0x73-  0x77 

TSPI/CTS  Data,  Format  3-Format  7 

Reserved  for  future  use 

0x06 

0x78 

Controller  Area  Network  Bus 

CAN  Bus 

0x06 

0x79 

Fibre  Channel  Data,  Format  0 

Fibre  Channel  Data 

0x07 

0x7  A 

Fibre  Channel  Data,  Format  1 

Fibre  Channel  Data 

0x08 

0x7B  -  0x80 

Fibre  Channel  Data,  Formats  2-7 

Reserved  for  future  use 

0x08 
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f.  Sequence  Number.  This  byte  contains  a  value  representing  the  packet  sequence  number 
for  each  channel  ID.  This  is  simply  a  counter  that  increments  by  n  +  0x01  to  OxFF  for 
every  packet  transferred  from  a  particular  channel  and  is  not  required  to  start  at  0x00  for 
the  first  occurrence  of  a  packet  for  the  channel  ID. 


NOTE /% 

The  sequence  number  counter  value  for  each 

channel  in  a  session  (e.g.,  recording)  will  repeat 

<r 

(rollover  to  0x00)  after  the  sequence  number 

counter  has  reached  OxFF. 

NOTE 


y 


Each  channel  in  a  session  shall  have  its 
own  sequence  counter  providing  a  unique 
sequence  number  for  that  channel. 


g.  Packet  Flags.  This  byte  contains  bits  representing  information  on  the  content  and  format 

of  the  packet(s). 

Bit  7:  Indicates  the  presence  or  absence  of  the  packet  secondary  header. 

0  =  Packet  secondary  header  is  not  present. 

1  =  Packet  secondary  header  is  present. 

Bit  6:  Indicates  the  IPTS  time  source. 

0  =  Packet  header  48-bit  RTC. 

1  =  Packet  secondary  header  time  (bit  7  must  be  1). 

Bit  5:  RTC  sync  error. 

0  =  No  RTC  sync  error. 

1  =  RTC  sync  error  has  occurred. 

Bit  4:  Indicates  the  data  overflow  error. 

0  =  No  data  overflow. 

1  =  Data  overflow  has  occurred. 

Bits  3-2:  Indicate  the  packet  secondary  header  time  format. 

00  =  Chapter  4  binary  weighted  48-bit  time  format.  The  two  lsbs  of  the  64-bit 
packet  secondary  header  time  and  IPTS  shall  be  zero-filled. 

01  =  IEEE  1588  time  format.  The  packet  secondary  header  time  and  each  IPTS 

shall  contain  a  64-bit  timestamp  represented  in  accordance  with  (IAW)  the 
time  representation  type  as  specified  by  IEEE  STD  1588-2008. 1  The  32 
bits  indicating  seconds  shall  be  placed  into  the  MSLW  portion  of  the 
secondary  header  and  the  32  bits  indicating  nanoseconds  shall  be  placed 
into  the  LSLW  portion. 


1  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  standard  for  a  precision  clock  synchronization  protocol  for 
networked  measurement  and  control  systems.  IEEE  1588-2008.  Geneva:  International  Electrotechnical 
Commission,  2008. 
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10  =  64-bit  binary  extended  relative  time  counter  (ERTC)  with  1 -nanosecond 

resolution.  The  counter  shall  be  derived  from  a  free -running  1 -gigahertz 
(GHz)  clock  -  similar  to  the  RTC  described  below  -  just  with  higher 
resolution.  When  this  option  is  used,  the  10-megahertz  (MHz)  RTC  shall 
be  synchronized  with  the  ERTC  (RTC  =  ERTC/ 100). 

11=  Reserved 

Bits  1-0:  Indicate  data  checksum  existence. 

00  =  No  data  checksum  present 
01  =  8-bit  data  checksum  present 
10  =  16-bit  data  checksum  present 
11=  32-bit  data  checksum  present 


h.  Data  Type.  This  byte  contains  a  value  representing  the  type  and  format  of  the  data.  All 
values  not  used  to  define  a  data  type  are  reserved  for  future  data  type  growth.  Table  11-4 
lists  the  data  types  and  their  descriptions. 


i.  Relative  Time  Counter.  These  6  bytes  contain  a  value  representing  the  10-MHz  RTC. 
This  is  a  free-running  10-MHz  binary  counter  represented  by  48  bits  that  are  common  to 
all  data  channels.  The  counter  shall  be  derived  from  a  10-MHz  internal  crystal  oscillator 
and  shall  remain  free-running  during  each  session  (e.g.,  recording). 


If  enabled,  the  applicable  data  bit  of  the  48-bit  value  of  the  packet 
secondary  time  value  shall  correspond  to  the  first  bit  of  the  data  in 
the  packet  body  (unless  it  is  defined  in  each  data  type  section). 


j.  Header  Checksum.  These  2  bytes  contain  a  value  representing  a  16-bit  arithmetic  sum  of 
all  16-bit  words  in  the  header  excluding  the  header  checksum  word. 

11.2.1.2  Packet  Secondary  Header  (Optional) 

The  length  of  the  packet  secondary  header  is  fixed  at  12  bytes  (96  bits).  The  packet 
secondary  header  is  optional  and  when  enabled  shall  consist  of  the  three  fields,  positioned 
contiguously,  in  the  following  sequence. 

a.  Time.  These  8  bytes  contain  the  value  representing  time  in  the  format  indicated  by  bits  2 
and  3  of  the  packet  flags  in  Subsection  11.2.1.1  item  g.  The  secondary  header  can  be 
enabled  on  a  channel-by-channel  basis  but  all  channels  that  have  a  secondary  header  must 
use  the  same  time  source  in  bits  2-3  of  the  packet  flags. 


NOTE 

The  applicable  data  bit  to  which  the  48-bit  value  of  the  packet 

/r 

secondary  time  value  (if  enabled)  applies  shall  correspond  to 

r 

the  first  bit  of  the  data  in  the  packet  body  (unless  it  is  defined  in 

each  data  type  section). 

When  Chapter  4  binary  weighted  time  is  used,  time  shall  be  stored  as  shown  in  Figure 
11-4. 
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Figure  11-4. 

Secondary  Header  Chapter  4  Time 

When  IEEE  1588  time  is  used  time  shall  be  stored  as  shown  in  Figure  11-5. 
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Secondary  Header  IEEE  1588  Time 

When  ERTC  time  is  used  time  shall  be  stored  as  shown  in  Figure  1 1-6. 
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Figure  11-6.  Secondary  Header  ERTC  Time 


b.  Reserved.  These  2  bytes  are  reserved  and  shall  be  zero  filled. 

c.  Secondary  Header  Checksum.  These  2  bytes  contain  a  value  representing  a  16-bit 
arithmetic  sum  of  all  secondary  header  bytes  excluding  the  secondary  header  checksum 
word. 

11.2.1.3  Packet  Body 

The  format  of  the  data  in  the  packet  body  is  unique  to  each  data  type.  Detailed 
descriptions  of  the  type-specific  data  formats  found  in  packet  bodies  are  described  in  subsequent 
sections  of  this  document. 

a.  Channel-Specific  Data.  Variable  in  size,  this  contains  the  contents  of  the  channel- 
specific  data  field(s)  depending  on  the  Data  Type  field  in  the  packet  header.  Channel- 
specific  data  is  mandatory  for  each  data  type  and  channel.  The  occurrence  of  channel- 
specific  data  is  once  per  packet  and  precedes  packet  channel  data. 

b.  Intra-Packet  Time  Stamp.  These  8  bytes  contain  time  in  either  48-bit  RTC  format  (plus 
16  high-order  zero  bits)  or  64-bit  format  as  specified  in  the  packet  flags  in  the  packet 
header.  The  IPTSs  are  only  mandatory  where  defined  by  the  data  formats. 

c.  Intra-Packet  Data  Header.  Variable  in  size,  this  contains  additional  time  status,  data, 
and/or  format  information  pertaining  to  the  data  items  that  follow.  The  IPDHs  are  only 
mandatory  where  defined  by  the  data  formats. 

d.  Data.  With  n  bytes,  this  contains  valid  data  from  a  particular  channel  as  defined  within 
the  data  formats  contained  within  this  standard. 
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NOTE 


The  IPTS  and  the  IPDH  are  collectively  called  the  IPH.  In  some  cases,  an 
IPH  may  only  have  a  timestamp  (zero-length  data  header),  while  in  other 
cases,  the  IPH  only  has  a  data  header  (zero-length  timestamp).  Some  data 
types  have  no  IPH.  The  IPH  requirements  are  specified  separately  for  each 
datatype. 


NOTE 


The  IPDH  presence,  once  set,  shall  be  the  same 
state  for  the  entire  session  (e.g.,  recording)  per 
each  channel 


11.2.1.4  Packet  Trailer 

The  packet  trailer  may  contain  filler,  a  data  checksum,  both  filler  and  a  data  checksum,  or 
neither  filler  nor  a  data  checksum.  In  the  latter  case,  the  packet  trailer  has  zero  length.  The 
reason  a  packet  trailer  would  have  a  zero  length  is  best  explained  by  understanding  the  reason  for 
inserting  filler.  The  purpose  of  the  filler  is  twofold: 

a.  To  keep  all  packets  aligned  on  32-bit  boundaries  (i.e.,  make  all  packet  lengths  a  multiple 
of  4  bytes);  and 

b.  To  optionally  keep  all  packets  from  a  particular  channel  the  same  length. 

If  both  of  the  above  requirements  are  already  met  without  adding  filler,  then  filler  shall 
not  be  added. 

The  inclusion  of  the  data  checksum  is  optional  as  well  and  is  indicated  by  the  packet  flags 
setting.  When  included,  the  packet  trailer  contains  either  an  8-bit,  16-bit,  or  32-bit  data 
checksum.  Depending  on  the  packet  flags  option  selected,  the  data  checksum  is  the  arithmetic 
sum  of  all  of  the  bytes  (8  bits),  words  (16  bits),  or  long  words  (32  bits)  in  the  packet  excluding 
the  24  bytes  of  packet  header,  packet  secondary  header  (if  enabled),  and  the  data  checksum. 
Stated  another  way,  the  data  checksum  includes  everything  in  the  packet  body  plus  all  added 
filler. 

a.  Filler.  Variable  in  size,  all  filler  shall  be  set  to  0x00  or  OxFF. 

b.  8-Bit  Data  Checksum.  This  1  byte  contains  a  value  representing  an  8 -bit  arithmetic  sum 
of  the  bytes  in  the  packet.  It  is  only  inserted  if  the  packet  flag  bits  are  set  (see  Subsection 
11.2.1.1  item  g). 

c.  16-Bit  Data  Checksum.  These  2  bytes  contain  a  value  representing  a  16-bit  arithmetic 
sum  of  the  words  in  the  packet.  It  is  only  inserted  if  the  packet  flag  bits  are  set 
(Subsection  11.2.1.1  item  g). 

d.  32-Bit  Data  Checksum.  These  4  bytes  contain  a  value  representing  a  32-bit  arithmetic 
sum  of  the  long  words  in  the  packet  and  is  only  inserted  if  packet  flag  bits  are  set 
(Subsection  11.2.1.1  item  g). 

11.2.2  PCM  Data  Packets 

1 1.2.2. 1  PCM  Data  Packets  Format  0 
Reserved. 


11-11 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


1 1.2. 2. 2  PCM  Data  Packets  Format  1  (Chapter  4  and  Chapter  8) 

A  packet  with  Chapter  4  or  Chapter  8  PCM  data  has  the  basic  structure  as  shown  in  Table 
11-5.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  table  merely 
represents  relative  placement  of  data  in  the  packet. 


Table  11-5.  General  PCM  Data  Packet,  Format  1 

Packet  Header 

Channel-Specific  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

(Optional)  Intra-Packet  Time  Stamp 

(Optional)  Intra-Packet  Data  Header 

Minor  Frame  Data 

Packet  Trailer 

The  user  may  separately  enable  or  disable  word  unpacking  on  each  active  PCM  channel. 
Word  unpacking  will  force  the  lsb  of  each  word  to  be  aligned  on  a  16-bit  boundary.  High-order 
filler  bits  are  added  to  words  as  necessary  to  force  alignment. 

The  user  may  separately  enable  or  disable  frame  synchronizing  on  each  active  PCM 
channel.  This  provides  a  throughput  mode  that  will  transfer  data  to  the  packet  without  frame 
synchronization.  Throughput  mode  essentially  disables  all  setup  and  packing/unpacking  options 
for  the  packet,  and  places  data  in  the  packet  as  it  is  received. 


a.  PCM  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  PCM  packet 
begins  with  the  channel-specific  data,  which  is  formatted  as  shown  in  Figure  11-7. 


msb 

31 

30 

29 

28 

27  24 

23 

18 

17 

lsb 

0 

R 

IPH 

MA 

MI 

LOCKST 

MODE 

SYNCOFFSET 

Figure  11-7.  Pulse  Code  Modulation  Packet  Channel-Specific  Data 

Format 


•  Reserved.  Bit  31  is  reserved. 
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•  Intra-Packet  Header.  Bit  30  indicates  if  IPHs  (IPTS  and  IPDH)  are  inserted  before 
each  minor  frame.  The  IPHs  are  only  optional  because  of  the  mode  selection.  This 
determines  whether  IPHs  are  included  or  omitted. 


0  =  The  IPHs  are  omitted  for  throughput  mode. 

1  =  The  IPHs  are  required  for  packed  data  and  unpacked  data  modes. 

•  Major  Frame  Indicator  (MA).  Bit  29  indicates  if  the  first  word  in  the  packet  is  the 
beginning  of  a  major  frame.  This  bit  is  not  applicable  for  throughput  mode. 

0  =  The  first  word  is  not  the  beginning  of  a  major  frame. 

1  =  The  first  word  is  the  beginning  of  a  major  frame. 

•  Minor  Frame  Indicator  (MI).  Bit  28  indicates  if  the  first  word  in  the  packet  is  the 
beginning  of  a  minor  frame.  This  bit  is  not  applicable  for  throughput  mode. 

0  =  The  first  word  is  not  the  beginning  of  a  minor  frame. 

1  =  The  first  word  is  the  beginning  of  a  minor  frame. 


•  Lock  Status  (LQCKST).  Bits  27-24  indicate  the  lock  status  of  the  frame 
synchronizer.  This  bit  is  not  applicable  for  throughput  mode. 


NOTE 


Minor  Frame  Definition.  The  minor  frame  is  defined  as  the  data  structure  in 
time  sequence  from  the  beginning  of  a  minor  frame  synchronization  pattern 
to  the  beginning  of  the  next  minor  frame  synchronization  pattern.  Please 
refer  to  Chapter  4,  Subsection  4.3.2  for  minor/major  frame  definition. 


Bits  27-26:  Indicate  minor  frame  status. 

00  =  Reserved. 

01  =  Reserved. 

10  =  Minor  frame  check  (after  losing  lock). 

11=  Minor  frame  lock. 

Bits  25-24:  Indicate  major  frame  status. 

00  =  Major  frame  not  locked. 

01  =  Reserved. 

10  =  Major  frame  check  (after  losing  lock). 

11=  Major  frame  lock. 

•  Mode  (MODE).  Bits  23-18  indicate  the  data  packing  mode. 

Bits  23-22:  Reserved. 

Bit  2 1 :  Alignment  Mode. 

0  =  16-bit  alignment  mode  enabled. 

1  =  32-bit  alignment  mode  enabled. 

Bit  20:  Indicates  throughput  data  mode. 

0  =  Throughput  data  mode  not  enabled. 

1  =  Throughput  data  mode  enabled. 

Bit  19:  Indicates  packed  data  mode. 
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0  =  Packed  data  mode  not  enabled. 

1  =  Packed  data  mode  enabled. 

Bit  18:  Indicates  unpacked  data  mode. 

0  =  Unpacked  data  mode  not  enabled. 

1  =  Unpacked  data  mode  enabled. 

•  Sync  Offset  (SYNCQFFSET).  Bits  17-0  contain  an  18-bit  binary  value  representing 
the  word  offset  into  the  major  frame  for  the  first  data  word  in  the  packet.  The  sync 
offset  is  not  applicable  for  packed  or  throughput  mode. 

b.  PCM  Packet  Body.  After  the  channel- specific  data,  the  IPHs  and  the  PCM  data  are 
inserted  in  the  packet  in  integral  numbers  of  minor  or  major  frames  unless  the  packet  is  in 
throughput  mode.  In  throughput  mode,  there  is  no  frame  or  word  alignment  to  the  packet 
data  and  no  IPHs  are  inserted  in  the  data.  In  both  packed  and  unpacked  modes,  minor 
frame  alignment  is  dependent  on  the  MODE  field  in  the  channel- specific  data.  In  16-bit 
alignment  mode,  PCM  minor  frames  begin  and  end  on  16-bit  boundaries.  In  32-bit 
alignment  mode,  PCM  minor  frames  begin  and  end  on  32-bit  boundaries.  In  either  case, 
alignment  mode  does  not  affect  the  format  of  PCM  data  words  themselves;  however, 
depending  on  perspective,  word  order  is  affected  and  a  zero-filled  data  word  may  be 
required  to  maintain  alignment. 

c.  PCM  Data  in  Unpacked  Mode.  In  unpacked  mode,  packing  is  disabled  and  each  data 
word  is  padded  with  the  number  of  filler  bits  necessary  to  align  the  first  bit  of  each  word 
with  the  next  16-bit  boundary  in  the  packet.  For  example,  4  pad  bits  are  added  to  12-bit 
words,  6  pad  bits  are  added  to  10-bit  words,  etc.  In  32-bit  alignment  mode,  a  zero-filled 
16-bit  word  is  required  to  maintain  alignment  when  an  odd  number  of  16-bit  words  exists 
in  the  minor  frame. 

Minor  frame  sync  patterns  larger  than  16  bits  are  divided  into  two  words  of  packet  data. 

If  the  sync  pattern  has  an  even  number  of  bits,  then  it  will  be  divided  in  half  and  placed  in 
two  packet  words.  For  example,  a  24-bit  sync  pattern  is  broken  into  two  12-bit  words 
with  4  bits  of  pad  in  each  word.  If  the  sync  pattern  has  an  odd  number  of  bits,  it  is 
broken  into  two  words  with  the  second  word  having  one  bit  more  of  the  sync  pattern.  For 
example,  if  the  minor  sync  pattern  is  25  bits,  then  the  first  sync  word  is  12  bits  of  sync 
pattern  plus  4  bits  of  pad,  and  the  second  sync  word  is  13  bits  of  sync  pattern  plus  3  bits 
of  pad. 

Minor  frame  sync  patterns  larger  than  32  bits  are  divided  into  (number  of  bits+15)/16 
words  in  16-bit  alignment  mode  or  (number  of  bits+3 1  )/32  in  32-bit  alignment  mode.  If 
the  sync  word  doesn’t  fill  the  words  completely,  the  first  word  shall  contain  the  lesser 
number  of  bits  with  the  later  words  containing  one  bit  more  (in  the  manner  described 
above  in  splitting  frame  sync  pattern  words  into  two  words).  For  example,  a  35-bit  sync 
word  shall  be  split  into  11+1 2+ 1 2-bit  words  in  16-bit  alignment  mode,  or  into  17+18-bit 
words  in  32-bit  alignment  mode. 

Given  PCM  frames  with  a  24-bit  minor  sync  pattern  and  n  data  words  where  the  bit- 
lengths  of  data  words  1,  2,  and  3  are  12,  16,  and  8  respectively,  the  resultant  16-bit 
alignment  mode  PCM  packets  are  as  shown  in  Table  11-6.  Given  PCM  frames  with  a  24- 
bit  minor  sync  pattern  and  n  data  words  where  the  bit-lengths  of  data  words  1,  2,  3,  and  4 
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are  12,  16,  8,  and  10  respectively,  the  resultant  32-bit  alignment  mode  PCM  packets  are 
as  shown  in  Table  11-7. 


Table  11-6. 


PCM  Data-Unpacked  (16-Bit  Alignment 
Mode)  Sample  Packet 


msb 

15 


lsb 

0 


Packet  Header 


Channel-Specific  Data  (Bits  15-0) 


Channel-Specific  Data  (Bits  31-16) 


Intra-Packet  Time  Stamp  (Bits  15-0) 


Intra-Packet  Time  Stamp  (Bits  31-16) 


Intra-Packet  Time  Stamp  (Bits  47-32) 


Intra-Packet  Time  Stamp  (Bits  63-48) 


Intra-Packet  Data  Header  (Bits  15-0) 


4  Bits  Pad 


12  Bits  Sync  (Bits  23-12) 


4  Bits  Pad 


12  Bits  Sync  (Bits  11-0) 


4  Bits  Pad 


12  Bits  Word  1  Data 


16  Bits  Word  2  Data 


8  Bits  Pad 


8Bits  Word  3  Data 


Word  N  Data  Bits  +  Pad  if  Needed 
Intra-Packet  Time  Stamp  (Bits  15-0) 
Intra-Packet  Time  Stamp  (Bits  31-16) 
Intra-Packet  Time  Stamp  (Bits  47-32) 
Intra-Packet  Time  Stamp  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 


Repeat  for  each  minor  frame. 


Packet  Trailer 


Table  11-7.  PCM  Data-Unpacked  (32-Bit  Alignment 
Mode)  Sample  Packet 

msb  lsb 

15 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 
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Intra-Packet  Data  Header  (Bits  15-0) 


Intra-Packet  Data  Header  (Bits  31-16) 


4  Bits  Pad 

12  Bits  Sync  (Bits  11-0) 

4  Bits  Pad 

12  Bits  Sync  (Bits  23-12) 

16  Bits  Word  2  Data 


4  Bits  Pad 

12  Bits  Word  1  Data 

6  Bits  Pad 

10  Bits  Word  4  Data 

8  Bits  Pad 

8  Bits  Word  3  Data 

Word  N  Data  Bits  +  Pad  If  Needed 
Intra-Packet  Time  Stamp  (Bits  15-0) 
Intra-Packet  Time  Stamp  (Bits  31-16) 
Intra-Packet  Time  Stamp  (Bits  47-32) 
Intra-Packet  Time  Stamp  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 


Repeat  for  each  minor  frame. 


Packet  Trailer 


d.  PCM  Data  in  Packed  Mode.  In  packed  mode,  packing  is  enabled  and  pad  is  not  added  to 
each  data  word;  however,  filler  bits  may  be  required  to  maintain  minor  frame  alignment. 
The  number  of  filler  bits  is  dependent  on  the  alignment  mode,  where  N  is  either  16  or  32. 
If  the  number  of  bits  in  the  minor  frame  is  not  an  integer  multiple  of  N,  then  Y  pad  bits 
will  be  added  to  the  end  of  each  minor  frame  of  bit  length  L.  Either  Y  =  N-MOD(L,N), 
or  N  minus  the  integer  remainder  when  L  is  divided  by  N.  In  packed  mode,  the  PCM 
stream  is  minor-frame  synchronized  so  the  first  data  bit  in  the  packet  is  the  first  data  bit 
of  a  minor  frame.  If  X  =  N  -  Y  when  N  is  16-bit  alignment  mode,  then  the  resultant 
PCM  packets  are  as  shown  in  Table  1 1-8.  Table  11-9  shows  the  resultant  PCM  packets 
for  32-bit  alignment  mode. 

Table  11-8.  PCM  Data-Packed  (16-Bit  Alignment  Mode) 

Sample  Packet 

msb  lsb 

J_5 _ 0_ 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 
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Data  (Bits  15-0) 

Data  (Bits  31-16) 

Data  (Bits  47-32) 

Y  Filler  Bits  X  Data  Bits 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Repeat  for  each  minor  frame. 

Packet  Trailer 

Table  11-9.  PCM  Data-Packed  (32-Bit  Alignment  Mode) 

Sample  Packet 

msb  lsb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

;  Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  3 1  - 1 6) 

Data  Word  2 

Data  Word  1 

Data  Word  4 

Data  Word  3 

Filler  Bits  X  Data  Bits 

16  Filler  Bits  (If  Required  to  Maintain  32-Bit  Alignment) 

Intra-Packet  Time  Stamp  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  47-32) 

Intra-Packet  Time  Stamp  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 

Repeat  for  each  minor  frame. 
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Packet  Trailer 


e.  PCM  Data  in  Throughput  Mode.  In  throughput  mode,  the  PCM  data  are  not  frame 
synchronized  so  the  first  data  bit  in  the  packet  can  be  any  bit  in  the  major  frame.  The 
resultant  PCM  packets  are  as  shown  in  Table  11-10  and  Table  11-11. 

Table  11-10.  PCM  Data-Throughput  (16-Bit  Alignment 
Mode)  Sample  Packet 

msb  lsb 

J_5 _ 0_ 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Data  (Bits  15-0) _ 

Data  (Bits  31-16) _ 

Data  (Bits  47-32) 


Packet  Trailer 


Table  11-11.  PCM  Data-Throughput  (32-Bit  Alignment 
Mode)  Sample  Packet 

msb  lsb 

15 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

PCM  Stream  Bits  17-32 
PCM  Stream  Bits  1-16 
PCM  Stream  Bits  49-64 
PCM  Stream  Bits  33-48 


Packet  Trailer 


f.  PCM  Data  Word  Order  in  32-Bit  Alignment  Mode.  When  acquitting  data  in  32-bit 

alignment  mode,  the  resultant  data  word  ordering  will  differ  from  16-bit  alignment  mode. 
The  serial  PCM  data  stream  is  shifted  into  32-bit  words  from  right  to  left,  with  bit  31  on 
the  left,  bit  0  on  the  right,  and  addresses  ascending  from  top  to  bottom.  Word  order  is 
affected  depending  on  the  reader’s  addressing  perspective.  For  example,  16-bit  data 
words  when  addressed  as  32-bit  words  appear  in  order  when  read  from  left  to  right  and 
top  to  bottom;  however,  when  addressed  as  16-bit  words,  each  pair  of  data  words  will 
appear  swapped.  Figure  11-8  and  Figure  11-9  depict  the  anomaly  of  perspective. 
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msb  lsb 

31  16  15  0 

Address 

Byte  3  Byte  2 

Byte  1  Byte  0 

Data  Word  1 

Data  Word  2 

0 

Data  Word  3 

Data  Word  4 

1 

Data  Word  N-l 

Data  Word  N 

(N/2)-l 

Figure  1 1-8.  32-Bit  Alignment  Mode  Example,  16-Bit  Data  Words  (32- 

Bit  Word  Addressing) 


Figure 


msb  lsb 

15  0 

Address 

Byte  1  Byte  0 

Data  Word  2 

0 

Data  Word  1 

1 

Data  Word  4 

2 

Data  Word  3 

3 

Data  Word  N-l 

N-l 

1-9.  32-Bit  Alignment  Mode  Example,  16-Bit  Data  Words  (16- 
Bit  Word  Addressing) 


g.  PCM  Intra-Packet  Header.  When  acquiring  data  in  packed  or  unpacked  mode,  all  PCM 
minor  frames  shall  include  an  IPH  containing  a  64-bit  IPTS  and  a  16-  or  32-bit  IPDH,  as 
indicated  by  MODE  in  the  channel- specific  data.  This  header  is  inserted  immediately 
before  the  minor  frame  sync  pattern.  Depending  on  alignment  mode,  the  length  of  the 
IPH  is  either  10  or  12  bytes  (80  or  96  bits)  positioned  contiguously,  as  depicted  in  Figure 
1 1-10.  In  16-bit  alignment  mode,  the  IPDH  length  is  fixed  at  2  bytes.  A  32-bit  alignment 
mode  requires  a  4-byte  IPDH,  and  the  two  most  significant  bytes  are  zero-filled. 


msb 

lsb 

31 

16 

15 

12 

11 

0 

Time  (FSFW) 

Time  (MSFW) 

Zero  Filled 

FOCKST 

RESERVED 

Figure  1 1-10.  Pulse  Code  Modulation  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  PCM  minor 
frame.  This  time  stamp  is  not  applicable  for  throughput  mode.  First  long  word  bits 
and  second  long  word  bits  indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  minor  frame  with 
bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  Absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  minor  frame. 
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•  Intra-Packet  Data  Header 

o  32-Bit  Alignment  (32-Bit  Alignment  mode  ONLY).  Bits  31-16  are  zero- 
filled. 

o  Lock  Status  (LOCKST).  Bits  15-12  indicate  the  lock  status  of  the  frame 
synchronizer  for  each  minor  frame. 

o  Bits  15-14:  Indicates  minor  frame  status. 

00  =  Reserved 
01  =  Reserved 

10  =  Minor  frame  check  (after  losing  lock) 

11=  Minor  frame  lock 

o  Bits  13-12:  Indicates  major  frame  status. 

00  =  Major  frame  not  locked 
01  =  Reserved 

10  =  Major  frame  check  (after  losing  lock) 

11  =  Major  frame  lock 

o  Reserved.  Bits  11-0  are  reserved. 


11.2.3  Time  Data  Packets 


1 1.2.3. 1  Time  Data  Packets,  Format  0.  Reserved. 

11.2.3.2  Time  Data  Packets,  Format  1  (IRIG/GPS/RTC) 

Time  is  treated  like  another  data  channel.  If  a  time  source  other  than  NONE  is  used 
(Figure  11-11),  the  time  packet  will  be  generated  at  a  minimum  frequency  of  1  hertz. 


msb 

31 

16 

15 

12 

11  8 

7 

4 

3 

lsb 

0 

Reserved 

ITS 

DATE 

FMT 

SRC 

Figure  11-11.  Time  Packet  Channel-Specific  Data  Format 


•  Inter-Range  Instrumentation  Group  (IRIG)  Time  Type  Formats.  The  10-MHz  RTC 
shall  be  captured  for  insertion  into  the  time  packet  data  header  IAW  IRIG  200. 2 


•  All  Non-IRIG  Time  Type  Formats.  The  10-MHz  RTC  shall  be  captured  for  insertion 
into  the  time  packet  data  header  consistent  with  the  resolution  with  the  time  packet 
body  format  (10  milliseconds  [ms]  as  measured  by  the  10-MHz  RTC). 


A  time  data  packet  shall  be  the  first  dynamic  data  packet  at  the  start 
of  each  session.  Only  static  Computer-Generated  Data,  Format  1 
packets  may  precede  the  first  time  data  packet. 


2  Range  Commanders  Council.  “IRIG  Serial  Time  Code  Formats.”  RCC  200-16.  August  2016.  Maybe 
superseded  by  update.  Retrieved  27  April  2017.  Available  at  http://www.wsmr.army.mil/RCCsite/Documents/200- 
16  IRIG  Serial  Time  Code  Formats/. 
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If  the  time  data  packet  source  is  None,  at  least 
one  time  data  packet  is  required  IAW  the 
previous  note. 


A  packet  with  time  data  has  the  basic  structure  shown  in  Table  11-12.  Note  that  the 
width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  to  represent 
relative  placement  of  data  in  the  packet.  Time  packets  do  not  have  IPHs. 

Table  11-12.  General  Time  Data  Packet,  Format  1 

Packet  Header 

Channel-Specific  Data _ 

Time  Data 
Packet  Trailer 


a.  Time  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  time  data  packet 
begins  with  a  CSDW  formatted  as  shown  in  Figure  11-11. 

•  Reserved.  Bits  31-16  are  reserved. 

•  IRIG  Time  Source  (ITS).  Bits  15-12  provide  dynamic  information  regarding  the 
source  of  time  for  an  internal  IRIG  time  code  generator  (TCG)  when  FMT  is  IRIG-A, 
B,  or  G.  The  ITS  bits  can  toggle  depending  upon  quality/validity  of  sources. 

0000  =  IRIG  TCG  freewheeling  (no  or  loss  of  time  source) 

0001  =  IRIG  TCG  freewheeling  from  .TIME  command 
0010  =  IRIG  TCG  freewheeling  from  RMM  time 
0011  =  IRIG  TCG  locked  to  external  IRIG  time  signal 
0100  =  IRIG  TCG  locked  to  external  GPS 

0101  =  IRIG  TCG  locked  to  external  Network  Time  Protocol  (NTP) 

0110  =  IRIG  TCG  locked  to  external  Precision  Time  Protocol  (PTP) 

0111  =  IRIG  TCG  locked  to  external  embedded  time  from  input  track/channel 
such  as  PCM  or  MIL-STD-1553 
1000- 1111  =  Reserved 

•  Date  (DATE).  Bits  11-8  indicate  the  date  format.  All  bit  patterns  not  used  to  define  a 
date  format  type  are  reserved  for  future  growth. 

o  Bits  11-10:  Reserved. 

o  Bit  9:  Indicates  date  format. 

0  =  IRIG  day  available  (Figure  11-12) 

1  =  Month  and  year  available  (Figure  11-13) 
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Figure  1 1-12.  Time  Data-Packet  Format,  Day  Format 
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Figure  1 1-13.  Time  Data-Packet  Format,  Day,  Month,  and  Year  Format 


o  Bit  8:  Indicates  if  this  is  a  leap  year. 

0  =  Not  a  leap  year 
1  =  Is  a  leap  year 

•  Time  Format  (FMT).  Bits  7-4  indicate  the  time  data  packet  format. 

0x0  =  IRIG-B 
0x1  =  IRIG- A 
0x2  =  IRIG-G 
0x3  =  Real-Time  Clock 

0x4  =  Universal  Coordinated  Time  (UTC)  time  from  GPS 

0x5  =  Native  GPS  Time 

0x6  -  OxE  =  Reserved 

OxF  =  NONE  (time  packet  payload  invalid) 


•  Time  Source  (SRC).  Bits  3-0  indicate  the  source  of  the  time  in  the  payload  of  each 
time  packet. 

0x0  =  Internal  (time  derived  from  a  clock  in  the  recorder) 

0x1  =  External  (time  derived  from  a  clock  not  in  the  recorder) 

0x2  =  Internal  from  RMM  (time  derived  from  the  clock  in  the  RMM) 

0x3  -  OxE  =  Reserved 
OxF  =  None 


NOTE 


If  the  time  source  is  external  (0x1)  and  lock  on  the  external  source  is  lost  then 
the  time  source  shall  indicate  Internal  (0x0).  Once  lock  on  the  external  time 
source  is  regained,  time  source  shall  once  again  indicate  external  (0x1). 


b.  Time  Packet  Body.  After  the  CSDW,  the  time  data  words  are  inserted  in  the  packet  in 
binary-coded  decimal  format  as  shown  in  Figure  11-12  and  Figure  11-13  (units  of 
measure  presented  in  Table  11-13). 
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Table  11-13.  Units  of  Measure 

Tmn 

Tens  of  ms 

TDn 

Tens  of  days 

Hmn 

Hundreds  of  ms 

HDn 

Hundreds  of  days 

Sn 

Units  of  seconds 

On 

Units  of  months 

TSn 

Tens  of  Seconds 

TOn 

Tens  of  months 

Mn 

Units  of  minutes 

Yn 

Units  of  years 

TMn 

Tens  of  minutes 

TYn 

Tens  of  years 

Hn 

Units  of  hours 

HYn 

Hundreds  of  years 

THn 

Tens  of  hours 

OYn 

Thousands  of  years 

Dn 

Units  of  days 

0 

Always  zero 

1 1.2. 3. 3  Time  Data  Packets,  Format  2  (Network  Time) 

The  Format  2  Network  Time  packet  data  type  is  used  to  extract  and  encapsulate  absolute 
time  from  NTP  or  IEEE- 1588  PTP  and  time  tag  it  with  the  RTC.  The  Format  2  Network  Time 
packet  will  be  generated  at  a  minimum  frequency  of  1  hertz  unless  it  is  recorded  at  the  raw 
network  rate  of  the  NTP  or  PTP  frames. 


The  NTP  is  referenced  in  UTC  time  with  an  epoch  of  January  1,  1900.  The  NTP  time 
includes  leap  seconds. 


The  PTP  is  referenced  in  International  Atomic  Time  with  an  epoch  of  January  1,  1970. 
The  PTP  time  does  not  include  leap  seconds. 


A  time  data  packet  shall  be  the  first  dynamic  data  packet  at  the  start 
of  each  recording.  Only  static  Computer-Generated  Data,  Format  1 
packets  may  precede  the  first  time  data  packet  in  the  recording. 


The  Format  2  Network  Time  packet  has  the  basic  structure  shown  in  Table  11-14.  Note 
that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  to 
represent  relative  placement  of  data  in  the  packet.  Format  2  Network  Time  packets  do  not  have 
IPHs. 


Table  11-14.  General  Time  Data 
Packet,  Format  1 

Packet  Header 

Channel-Specific  Data _ 

Time  Data 
Packet  Trailer 


a.  Time  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  time  data  packet 
begins  with  a  CSDW  formatted  as  shown  in  Figure  11-14. 
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Figure  11-14.  Format  2  Network  Time  Packet  Channel-Specific  Data 

Format 


•  Reserved.  Bits  31-8  are  reserved. 

•  Network  Time  Format  (NTF).  Bits  7-4  indicate  the  time  data  packet  format. 

0x0  =  Network  Time  Protocol  Version  3  (Request  for  Comment  13053). 

0x1  =  IEEE-1588-2002 
0x2  =  IEEE-1588-2008 
0x3  -  OxF  =  Reserved 

•  Time  Status  (TS).  Bits  3-0  indicate  the  status  of  the  network  time. 

0x0  =  Time  Not  Valid 
0x1  =  Time  Valid 
0x2  -  0xF=  Reserved 

c.  Time  Packet  Body.  After  the  CSDW,  the  time  data  is  inserted  in  the  packet  as  shown  in 
Figure  11-15  for  NTP  and  Figure  11-16  for  PTP. 

msb  lsb 

_31 _ 0_ 

Time  Unsigned  Seconds _ 

Time  Unsigned  Seconds  Fractions 

Figure  11-15.  Format  2  Network  Time  Packet  NTP  Time  Data 


msb 

_31 _ 

Time  Unsigned  Seconds 
Time  Unsigned  Nanoseconds 

Figure  1 1-16.  Format  2  Network  Time  Packet  PTP  Time  Data 

11.2.4  MIF-STD-1553  Packets 

11.2.4.1  MIF-STD-1553  Bus  Data  Packets,  Format  0. 

Reserved. 

11.2.4.2  MIF-STD-1553  Bus  Data  Packets,  Format  1  (MIF-STD-1553B  Bus  Data) 

Data  in  the  MIF-STD-1553  bus  format  is  packetized  as  messages,  with  each  1553  bus 
transaction  recorded  as  a  message.  A  transaction  is  a  bus  controller  (BC)-to-remote  terminal 
(RT),  RT-to-BC,  or  RT-to-RT  word  sequence,  starting  with  the  command  word  and  including  all 


lsb 

0 


3  Internet  Engineering  Task  Force.  “Network  Time  Protocol  (Version  3)  Specification,  Implementation  and 
Analysis.”  RFC  1305.  March  1992.  Obsoleted  by  RFC  5905.  Retrieved  22  June  2017.  Available  at 
https://datatracker.ietf.org/doc/rfc  1 305/. 
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data  and  status  words  that  are  part  of  the  transaction,  or  a  mode  code  word  broadcast.  Multiple 
messages  may  be  encoded  into  the  data  portion  of  a  single  packet. 


a. 


MIL-STD-1553  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  MIL- 
STD-1553  data  packet  begins  with  a  CSDW  formatted  as  shown  in  Figure  11-17. 
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Figure  11-17.  MIL-STD-1553  Packet  Channel-Specific  Data  Format 


•  Time  Tag  Bits  (TTB).  Bits  31-30  indicate  which  bit  of  the  MIL-STD-1553  message 
the  IPH  time  tags. 

00  =  Last  bit  of  the  last  word  of  the  message 
01  =  First  bit  of  the  first  word  of  the  message 

10  =  Last  bit  of  the  first  (command)  word  of  the  message 

11  =  Reserved 

•  Reserved.  Bits  29-24  are  reserved. 

•  Message  Count  (MSGCOUNT).  Bits  23-0  indicate  the  binary  value  of  the  number  of 
messages  included  in  the  packet.  An  integral  number  of  complete  messages  will  be  in 
each  packet. 

b.  MIL-STD-1553  Packet  Body.  A  packet  within  MIL-STD-1553  messages  has  the  basic 
structure  shown  in  Table  11-15.  Note  that  the  width  of  the  structure  is  not  related  to  any 
number  of  bits.  This  drawing  is  merely  intended  to  represent  relative  placement  of  data 
in  the  packet. 


Table  11-15.  MIL-STD-1553  Data  Packet,  Format  1 

Basic  Layout 

Packet  Header 

Channel- Specific  Data 

Intra-Packet  Time  Stamp  for  Message  1 

Intra-Packet  Data  Header  for  Message  1 

Message  1 

Intra-Packet  Time  Stamp  for  Message  2 

Intra-Packet  Data  Header  for  Message  2 

Message  2 

Intra-Packet  Time  Stamp  for  Message  N 

Intra-Packet  Data  Header  for  Message  N 

Message  N 

Packet  Trailer 
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c.  MIL-STD-1553  Intra-Packet  Header.  After  the  channel- specific  data,  the  MIL-STD- 
1553  data  are  inserted  into  the  packet  in  messages.  Each  MIL-STD-1553  message  is 
preceded  by  an  IPH  consisting  of  an  IPTS  and  an  IPDH. 

(1)  MIL-STD-1553  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
MIL-STD-1553  message  as  follows. 

•  The  48-bit  RTC  that  corresponds  to  the  data  bit  indicated  in  the  MIL-STD- 
1553  channel-specific  data,  TTBs  (Subsection  11.2.4.2  item  a)  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  data  bit 
indicated  in  the  MIL-STD-1553  channel-specific  data,  TTBs  (Subsection 
11.2.4.2  item  a). 

(2)  MIL-STD-1553  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  6 
bytes  (48  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-18). 

msb 

J5 _ 

Block  Status  Word 
Gap  Times  Word 
Length  Word _ 

Ligure  11-18.  MIL-STD-1553  Intra-Packet  Data  Header 

•  Block  Status  Word  (BSW).  Bits  15-0  contain  the  block  status  word  for  both 
the  message  type  and  any  1553  bus  protocol  errors  that  occurred  during  the 
message  transfer.  The  block  status  word  bit  definitions  are  in  Ligure  11-19. 
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Ligure  11-19.  Block  Status  Word 


•  Reserved  (R).  Bits  15-14  are  reserved. 

•  Bus  ID  (BID).  Bit  13  indicates  the  bus  ID  for  the  message. 

0  =  Message  was  from  channel  A 
1  =  Message  was  from  channel  B 

•  Message  Error  (ME).  Bit  12  indicates  a  message  error  was 
encountered. 

0  =  No  message  error 
1  =  Message  error 

•  RT  to  RT  Transfer  (RR).  Bit  1 1  indicates  a,  RT  to  RT  transfer; 
message  begins  with  two  command  words. 

0  =  No  RT  to  RT  transfer 


lsb 

0 
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1  =  RT  to  RT  transfer 

•  Format  Error  (FE).  Bit  10  indicates  any  illegal  gap  on  the  bus  other 
than  response  timeout. 

0  =  No  format  error 
1  =  Format  error 

•  Response  Time  Out  (TM).  Bit  9  indicates  a  response  time  out 
occurred.  The  bit  is  set  if  any  of  the  status  word(s)  belonging  to  this 
message  didn’t  arrive  within  the  response  time  of  14  microseconds 
(ps)  defined  by  MIL-STD-1553B.4 

0  =  No  response  time  out 
1  =  Response  time  out 

•  Reserved.  Bits  8-6  are  reserved. 

•  Word  Count  Error  (LE).  Bit  5  indicates  that  the  number  of  data  words 
transmitted  is  different  than  identified  in  the  command  word.  A  MIL- 
STD-1553B  status  word  with  the  busy  bit  set  to  true  will  not  cause  a 
word  count  error.  A  transmit  command  with  a  response  timeout  will 
not  cause  a  word  count  error. 

0  =  No  word  count  error 
1  =  Word  count  error 

•  Sync  Type  Error  (SE).  Bit  4  indicates  an  incorrect  sync  type  occurred. 

0  =  No  sync  type  error 
1  =  Sync  type  error 

•  Invalid  Word  Error  (WE).  Bit  3  indicates  an  invalid  word  error 
occurred.  This  includes  Manchester  decoding  errors  in  the  sync 
pattern  or  word  bits,  invalid  number  of  bits  in  the  word,  or  parity  error. 

0  =  No  invalid  word  error 
1  =  Invalid  word  error 


•  Reserved.  Bits  2-0  are  reserved. 


NOTE 


Gap  Times  (response  time):  The  gap  times  word  indicates  RT  response  times 
as  defined  by  MIL-STD-1553.  The  resolution  of  the  response  time  shall  be  in 
tenths  of  ps.  A  maximum  of  two  response  time  words  can  exist.  Messages  of 
RT-to-RT  type  shall  have  two  response  time  words  if  both  terminals  respond; 
all  other  messages  will  have  one  response  time  word,  or  none  for  broadcast 
type  messages  or  messages  with  no  RT  response. 


•  Gap  Times  Word.  Bits  15-0  indicate  the  number  of  tenths  of  ps  in  length  of 
the  internal  gaps  within  a  single  transaction.  For  most  messages,  only  GAP1 


4  Department  of  Defense.  “Aircraft  Internal  Time  Division  Command/Response  Multiplex  Data  Bus.”  MIL-STD- 
1553B.  15  January  1996.  May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at 
http://quicksearch.dla.mil/qsDocDetails.aspx7ident  numbet-36973. 
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is  meaningful.  It  measures  the  time  between  the  command  or  data  word  and 
the  first  (and  only)  status  word  in  the  message.  For  RT-to-RT  messages, 
GAP2  measures  the  time  between  the  last  data  word  and  the  second  status 
word.  The  gap  times  word  bit  definitions  are  as  shown  in  Figure  11-20. 
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Figure  11-20.  Gap  Times  Word 


NOTE 


Gap  measurements  shall  be  made  IAW  MIL-STD-1553  response 
time  measurements  from  the  mid-bit  zero  crossing  of  the  parity  bit  of 
the  last  word  to  the  mid-zero  crossing  of  the  sync  of  the  status  word. 


•  Length  Word.  Bits  15-0  contain  the  length  of  the  message,  which  is  the  total 
number  of  bytes  in  the  message.  A  message  consists  of  command  words,  data 
words,  and  status  words. 


d.  Packet  Format.  Unless  an  error  occurred,  as  indicated  by  one  of  the  error  flags  in  the 
block  status  word,  the  first  word  following  the  length  word  shall  always  be  a  command 
word.  The  resultant  packets  have  the  format  shown  in  Table  11-16. 


Table  11-16.  MIL-STD-1553  Data  Packet,  Format  1 


msb 

lsb 

15 

0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 


_ Channel- Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 
Intra-Packet  Data  Header  for  Msg  1  (Bits  31-16) 
Intra-Packet  Data  Header  for  Msg  1  (Bits  47-32) 
Command  Word 

Command,  Status,  or  Data  Word _ 

Data  or  Status  Word 


Data  or  Status  Word 

Intra-Packet  Time  Stamp  for  Msg  2  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  2  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  2  (Bits  15-0) 
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Intra-Packet  Data  Header  for  Msg  2  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  2  (Bits  47-32) 

Command  Word 

Command,  Status,  or  Data  Word 

Data  or  Status  Word 

Data  or  Status  Word 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  N  (Bits  47-32) 

Command  Word 

Command  or  Data  Word 

Data  or  Status  Word 

Data  or  Status  Word 

Packet  Trailer 

11.2.4.3  MIL-STD-1553  Bus  Data  Packets,  Format  2  (Bus  16PP194  Weapons  Bus  Data) 

This  data  type  provides  packetization  for  the  F-16  MIL-STD-1553  weapons  multiplex 
bus  as  defined  in  document  16PP362B.5  A  16PP194  transaction  consists  of  six  each  32-bit 
words  consisting  of  a  16PP194  COMMAND  (1),  COMMAND  (1)  ECHO,  COMMAND  (2), 
COMMAND  (3)  GO/NOGO,  COMMAND  (4)  GO/NOGO,  and  STATUS  as  illustrated  in  Figure 
1 1-21.  Multiple  transactions  may  be  encoded  into  the  data  portion  of  a  single  packet. 


TX 


(i) 

(2) 

(4) 

(5) 

COMMAND  (1) 

COMMAND  (2) 

COMMAND  (3) 
GO/NO  GO 

COMMAND  (4) 
GO/NO  GO 

RX 


(3) 


COMMAND  (1) 
ECHO 


(6) 


STATUS 


Figure  1 1-21.  16PP194  Message  Transaction 


a.  MIL-STD-1553  16PP194  Packet  Channel-Specific  Data  Word.  The  packet  body  portion 
of  each  16PP  MIL-STD-1553  data  packet  begins  with  a  CSDW  formatted  as  shown  in 


5  Lockheed  Martin  Corporation.  “Advanced  Weapons  Multiplex  Data  Bus.”  8  June  2010.  May  be  superseded  by 
update.  Retrieved  27  April  2017.  Available  to  RCC  members  with  Private  Portal  access  at 
https://wsdmext.wsmr.army. mil/site/rccpri/Limited  Distribution  References/1 6PP362B.pdf. 
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Figure  11-22.  Bits  31-0  indicate  the  binary  value  of  the  number  of  messages  included  in 
the  packet.  An  integral  number  of  complete  transaction  messages  will  be  in  each  packet. 


lsb 

_0 

MSGCQUNT _ 

Figure  11-22.  Military  Standard  1553  16PP194  Packet  Channel- Specific 

Data  Format 


msb 

31 


b.  MIL-STD-1553  16PP194  Packet  Body.  A  packet  with  n  MIL-STD-1553  16PP194 

transactions  has  the  basic  structure  shown  in  Table  11-17  below.  This  drawing  is  merely 
to  represent  relative  placement  of  data  in  the  packet. 


Table  11-17.  MIL-STD-1553  16PP194  Data  Packet  Basic  Layout 


msb 

31 


Packet  Header 

16PP194  Channel-Specific  Data  Word 
Intra-Packet  Time  Stamp  (LSLW) 
Intra-Packet  Time  Stamp  (MSLW) 
Intra-Packet  Data  Header  Length  Word 
Data  1 


Intra-Packet  Data  Header  Status  Word 


lsb 

0 


Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

Intra-Packet  Data  Header  Length  Word 

Intra-Packet  Data  Header  Status  Word 

Data  N 

PACKET  TRAILER 


c.  MIL-STD-1553  16PP194  Intra-Packet  Header.  The  IPH  consists  of  the  IPDH  (LENGTH 
and  STATUS)  and  the  IPTS. 

•  MIL-STD-1553  16PP194  Intra-Packet  Data  Header  LENGTH.  The  length  word 
contains  the  length  in  bytes  of  the  intra-packet  data. 


NOTE 

The  intra-packet  length  is  fixed  to  0x18,  24 

r 

bytes. 

•  MIL-STD-1553  16PP194  Intra-Packet  Data  Header  STATUS.  The  status  word 

contains  error  and  special  handling  information  about  the  data.  When  set  to  a  “1”,  the 
error  indicator  bits  reflect  that  such  an  error  is  present  in  the  data  or  occurred  during 
data  reception.  The  format  of  the  status  word  is  shown  in  Ligure  11-23. 
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msb 
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13 

12 

7 

6 

5 

4 

3 

lsb 

2  0 

TE 

RE 

TM 

RESERVED 

SE 

R 

EE 

RESERVED 

Figure  11-23.  Military  Standard  1553  16PP194  Intra-Packet  Data  Header 

Format 


o  Transaction  Error  (TE).  Bit  15  indicates  an  error  condition  found  in  16PP194 
transaction. 

0  =  No  errors  found  in  current  transaction 
1  =  Error  condition  found  in  transaction 

o  Reset  (RE).  Bit  14  indicates  a  16PP194  bus  master  reset. 

0  =  No  master  reset 
1  =  Master  reset  assertion  detected 

o  Message  Time  Out  (TM).  Bit  13  indicates  a  transaction  time  out  occurred. 

0  =  No  message  time  out 
1  =  Message  time  out 

o  Reserved.  Bits  12-7  are  reserved. 

o  Status  Error  (SE).  Bit  6  indicates  status  word  missing  in  transaction. 

0  =  Status  word  present 
1  =  Status  word  missing 

o  Reserved  (R).  Bits  5-4  are  reserved. 

o  Echo  Error  (EE).  Bit  3  indicates  echo  word  missing  in  transaction. 

0  =  Echo  word  present 
1  =  Missing  echo  word 

o  Reserved.  Bits  2-0  are  reserved. 

•  MIL-STD-1553  16PP194  Intra-Packet  Time  Stamp.  The  IPTS  (64  bits  total)  contains 
a  48-bit  relative  time  stamp  in  the  low-order  bits.  The  16  high-order  bits  are  zero. 

d.  Packet  Format.  Unless  an  error  occurred,  as  indicated  by  one  of  the  error  flags  in  the 
IPDH,  the  first  word  following  the  length  should  always  be  the  first  transaction  command 
word.  The  resultant  packets  have  the  format  shown  in  Table  11-18. 

Table  11-18.  MIL-STD-1553  16PP194  Data  Packet 

msb  lsb 

J_5 _ 0_ 

Packet  Header _ 

Channel-Specific  Data  (Bits  15-0) 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  (Bits  0-15) 

_ Intra-Packet  Time  Stamp  (Bits  31-16) _ 
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Intra-Packet  Time  Stamp  (Bits  32-47) 

Intra-Packet  Time  Stamp  (Bits  48-63) 

Intra-Packet  Data  Header  Status 

Intra-Packet  Data  Header  Fength 

Command  (1)  (Bits  31-16) 

Command  (l)(Bits  15-0) 

Command  (1)  Echo(Bits  31-16) 

Command  (1)  Echo  (Bits  15-0) 

Command  (2)  (Bits  31-16) 

Command  (2)  (Bits  15-0) 

Command  (3)  Go  No-Go  (Bits  31-16) 

Command  (3)  Go  No-Go  (Bits  15-0) 

Command  (4)  Go  No-Go  Echo  (Bits  31-16) 

Command  (4)  Go  No-Go  Echo  (Bits  15-0) 

Status  (Bits  31-16) 

Status  (Bits  15-0) 

Intra-Packet  Time  Stamp  (Bits  0-15) 

Intra-Packet  Time  Stamp  (Bits  31-16) 

Intra-Packet  Time  Stamp  (Bits  32-47) 

Intra-Packet  Time  Stamp  (Bits  48-63) 

Intra-Packet  Data  Header  Status 

Intra-Packet  Data  Header  Length 

Command  (1)  (Bits  31-16) 

Command  (1)  (Bits  15-0) 

Command  (1)  Echo  (Bits  31-16) 

Command  (1)  Echo  (Bits  15-0) 

Command  (2)  (Bits  31-16) 

Command  (2)  (Bits  15-0) 

Command  (3)  Go  No-Go  (Bits  31-16) 

Command  (3)  Go  No-Go  (Bits  15-0) 

Command  (4)  Go  No-Go  Echo  (Bits  31-16) 

Command  (4)  Go  No-Go  Echo  (Bits  15-0) 

Status  (Bits  31-16) 

Status  (Bits  15-0) 

Packet  Trailer 

e.  MIL-STD-1553  16PP194  Data  Format.  Each  26-bit  16PP194  word  in  a  16PP194 

transaction  shall  be  formatted  into  two  16-bit  words  (Figure  11-24).  The  corresponding 
16PP194  sync  and  parity  bits  will  not  be  formatted  into  the  16PP194  words. 


msb 

15  13 

12  10 

9 

8 

lsb 

7  0 

BUS  ID 

GAP 

W 

P 

16PP194  Data  Word  (bits  24-17) 

16PP194  Data  Word  (bits  16-1) 

Figure  11-24.  Military  Standard  1553  26-Bit  16PP194  Word 
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MIL-STD-1553  16PP194  Bus  ID  (BUS  ID).  A  three-bit  field  shall  be  used  to 
indicate  bus  identification  as  follows. 


Ill 

Communication  interface 
unit  (CIU)  Left  Bus  A 

110 

CIU  Left  Bus  B 

101 

CIU  Right  Bus  A 

100 

CIU  Right  Bus  B 

Oil 

Response  Bus  A  and  B 

010 

Response  Bus  A 

001 

Response  Bus  B 

000 

Incomplete  Transaction 

MIL-STD-1553  16PP194  GAP  (GAP).  A  three-bit  field  shall  be  used  to  indicate 
GAP  between  transactions  as  follows. 


111 

GAP  >9.15  ps 

110 

7.55  ps<  GAP  <9.15  ps 

101 

5.95  ps<  GAP  <7.55  ps 

100 

4.35  ps  <  GAP  <  5.95  ps 

Oil 

2.75  ps<  GAP  <4.35  ps 

010 

2.75  ps<  GAP  <4.35  ps 

001 

1.15  ps  <  GAP  <  2.75  ps 

000 

Not  Applicable 

NOTE 

Gap  time  is  measured  from  mid-crossing  of  the 

r 

parity  bit  from  the  previous  received  word  to  mid- 

crossing  of  the  sync  bit  of  the  current  word  in  1-ps 

counts. 

MIL-STD-1553  16PP194  Word  Bit  Error  (W).  If  the  bit  is  set  to  “1,”  this  indicates 
that  a  Manchester  error  was  detected  in  the  word. 

MIL-STD-1553  16PP194  Word  Parity  Error  (P).  If  the  bit  is  set  to  “1,”  this  indicates 
that  a  parity  error  occurred  in  the  word. 

16PP194  Data  Word.  Bits  16-1  contain  the  16PP194  data  field  as  in  Figure  11-25. 
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MSB 


LSB 


16PP194  32-bit  Intra-Packet  Word  Format  (as  it  appears  in  the  data 
packet) 


Figure  11-25.  16PP 194  Word  Format 


•  16PP194  Data  Word.  Bits  24-17  contain  the  16PP 194  remote  interface  unit  (RIU) 

address  and  RIU  subaddress  as  in  Figure  11-25. 

11.2.5  Analog  Data  Packets 

1 1.2. 5.1  Analog  Data  Packets,  Format  0 

Reserved. 


1 1 .2.5.2  Analog  Data  Packets,  Format  1 

The  generic  packet  structure  for  analog  data  is  illustrated  in  Table  11-19. 


Table  11-19.  Generic  Analog  Data  Packet,  Format  1 

Packet  Header 

Channel- Specific  Data  Word,  Subchannel  1 

Channel- Specific  Data  Word,  Subchannel  2 

Channel- Specific  Data  Word,  Subchannel  M 

Sample  1 

Sample  2 

Sample  N 

Packet  Trailer 
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An  analog  data  packet  will  contain  a  CSDW  for  each  subchannel  of  analog  data  sampled 
within  that  packet  if  the  SAME  bit  is  set  to  0,  or  it  will  contain  a  single  CSDW  for  the  entire 
analog  packet  if  the  SAME  bit  is  set  to  1 .  This  will  be  followed  by  at  least  one  complete 
sampling  schedule  of  data. 

A  sampling  schedule  is  defined  as  a  sampling  sequence  in  which  each  subchannel, 
described  by  a  CSDW,  is  sampled  at  least  once.  In  many  cases,  due  to  simultaneous  sampling 
rules  and  varied  sampling  rates,  a  particular  subchannel  will  be  sampled  more  than  once  during  a 
sampling  schedule.  In  addition,  multiple  complete  sampling  schedules  may  be  included  in  a 
single  packet.  For  these  reasons,  the  number  of  CSDWs  will  usually  be  less  than  the  number  of 
samples. 


Table  11-19  depicts  the  generic  packet  data  structure  for  M  data  subchannels  and  a  single 
sampling  schedule  that  has  a  length  N.  Note  that  the  width  of  the  structure  is  not  related  to  any 
number  of  bits  and  is  merely  intended  to  represent  relative  placement  of  words  within  the  packet. 


NOTE 


y 


The  packet  header  time  in  an  analog  data  packet 
shall  correspond  to  the  first  data  sample  in  the 
packet.  There  are  no  IPHs  in  analog  data  packets. 


a.  Analog  Packet  Channel-Specific  Data.  The  packet  body  portion  of  each  analog  packet 
begins  with  the  CSDW(s).  Each  subchannel  that  is  sampled  with  the  packet  sampling 
schedule  must  have  a  CSDW  within  the  packet.  Only  one  CSDW  is  required  if 
subchannels  are  sampled  at  the  same  sampling  rate  (FACTOR),  and  have  the  same  bits 
per  sample  (LENGTH)  and  same  packing  mode  (MODE).  Bit  28  of  the  CSDW  shall  be 
used  to  indicate  same  sampling  data  rate  for  subchannels. 


The  CSDWs  for  analog  data  packets  are  formatted  as  shown  in  Figure  11-26. 


msb 

31  29 

28 

27  24 

23  16 

15 

8 

7 

2 

lsb 

1  0 

RESERVED 

SAME 

FACTOR 

TOTCHAN 

SUBCHAN 

LENGTH 

MODE 

Figure  1 1-26.  Analog  Packet  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-29  are  reserved. 

•  Same.  Bit  28  specifies  if  this  CSDW  applies  for  all  the  channels  included  in  the 
packet  or  if  each  channel  has  its  own  CSDW. 

0  =  Each  analog  channel  has  its  own  CSDW. 

1  =  The  CSDW  is  valid  for  all  analog  channels  stored  in  this  packet. 

•  Factor.  Bits  27-24  are  the  exponent  of  the  power  of  2  sampling  rate  factor 
denominator  for  the  corresponding  subchannel  in  the  range  0  to  15.  (The  sampling 
rate  factor  numerator  is  always  1.) 

0x0  =  Sampling  rate  factor  denominator  2°=  1  =  >  factor  =  1/1 

0x1  =  Sampling  rate  factor  denominator  2l=  2  =  >  factor  =  Vi 

0x2  =  Sampling  rate  factor  denominator  22=  4  =  >  factor  =  14 
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OxF  =  Sampling  rate  factor  denominator  215=  32768  =  >  factor  =  1/32768 

•  Totchan.  Bits  23-16  indicate  the  total  number  of  analog  subchannels  in  the  packet 
(and  the  number  of  CSDWs  in  the  packet). 

This  field  must  be  the  same  value  in  all  CSDWs  in  a  single  packet.  The  Totchan 
value  may  be  less  than  the  largest  Subchan  value.  This  can  happen  when  a  multi¬ 
channel  analog  input  device  has  some  of  its  subchannels  disabled  (turned  off)  for  a 
specific  acquisition  session.  For  example,  if  an  analog  input  device  has  eight 
subchannels  and  not  all  eight  are  active,  an  analog  data  packet  may  have  three 
subchannels  (Totchan  =  3)  numbered  4,  7,  and  8  (enabled  Subchan  =  4,  7,  8).  The 
number  of  subchannels  (Totchan)  and  the  subchannel  number  for  each  active 
subchannel  (Subchan)  in  a  packet  are  identified  in  the  accompanying  Telemetry 
Attributes  Transfer  Standard  (TMATS)  (Computer-Generated  Data,  Format  1)  packet. 

0x00  =  256  subchannels 
0x01  =  1  subchannel 
0x02  =  2  subchannels 

•  Subchan.  Bits  15-8  indicate  a  binary  value  representing  the  number  or  subchannel  ID 
of  the  analog  subchannel. 

When  an  analog  packet  contains  data  from  more  than  one  subchannel  and  the  CSDWs 
are  not  the  same  for  all  channels  (see  field  Same,  bit  28),  the  CSDWs  must  be 
inserted  into  the  packet  in  ascending  subchannel  number  as  identified  by  this  field. 
The  Subchan  values  in  these  CSDWs  need  not  be  contiguous  (see  Totchan),  but  they 
must  be  in  ascending  decimal  numerical  order  with  the  exception  that  subchannel  0 
(256)  is  last.  If  the  Same  bit  is  set,  the  Subchan  field  shall  be  set  to  zero. 

0x01  =  Subchannel  1 
0x02  =  Subchannel  2 

0x00  =  Subchannel  256 


•  Length.  Bits  7-2  indicate  a  binary  value  representing  the  number  of  bits  in  the 
analog-to-digital  converter. 

000000  =  64-bit  samples 
000001  =  1-bit  samples 

001000  =  8-bit  samples 

001100  =  12-bit  samples 


•  Mode.  Bits  1-0  indicate  alignment  and  packing  modes  of  the  analog  data.  When 
Totchan  is  more  than  1,  MODE  must  be  the  same  for  all  subchannels  in  a  single 
packet. 

00  =  Data  is  packed 

01  =  Data  is  unpacked,  lsb  padded 
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10  =  Reserved  for  future  definition 

11  =  Data  is  unpacked,  msb  padded 


NOTE 


For  the  special  case  of  defining  a  single  channel  (Totchan  =  1),  there  are 
two  options:  a)  one  channel  with  no  subchannels;  or  b)  one  channel  as  its 
own  subchannel.  In  such  cases  the  bits  are  to  be  defined  as  follows. 


One  channel  with 
no  subchannel 

One  channel  with 
one  subchannel 

Totchan  (bits  23-16) 

1 

1 

Same  (bit  28) 

1 

0 

Subchan  (bits  15-8) 

0 

1 

b.  Analog  Samples.  A  simultaneous  sampling  scheme  shall  be  employed  to  preserve  timing 
relationships  and  allow  for  accurate  reconstruction  of  the  data.  The  highest  sampling  rate 
required  shall  define  the  primary  simultaneous  sampling  rate  within  the  packet.  The 
primary  simultaneous  sampling  rate  is  identified  in  the  TMATS  file  describing  the 
attributes  of  the  analog  data  packet.  The  rate  at  which  the  other  subchannels  are  sampled 
is  then  defined  by  the  sampling  factor  (1,  Vi,  14,  1/8,  1/16,  1/32768)  for  each  subchannel. 
As  an  example,  a  sampling  factor  of  !4  would  yield  that  subchannel  being  sampled  at 
one-fourth  the  primary  simultaneous  sampling  rate  and  a  sampling  factor  of  1  would 
yield  that  subchannel  being  sampled  at  the  primary  simultaneous  sampling  rate. 


Directly  following  the  CSDW(s),  at  least  one  complete  sampling  schedule  shall  be 
inserted  in  the  packet.  The  samples,  within  the  sampling  sequence,  may  be  inserted 
either  unpacked,  msb  packed,  or  lsb  packed  as  described  in  Subsection  11.2.5.2  items 
b(l)  and  b(2).  In  either  case,  one  or  more  subchannels  may  be  included  in  a  single 
packet.  When  multiple  subchannels  are  encapsulated  into  a  single  packet,  the  subchannel 
with  the  highest  sampling  rate  requirement  defines  the  primary  simultaneous  sampling 
rate.  The  rate  at  which  the  other  subchannels  are  sampled  is  defined  by  the  sampling 
factor  (contained  within  the  CSDWs).  Sampling  factors  are  defined  as: 


(  i  3 


v2Ky 


*X 


K  =  0,  1,2,  3,  4,  5,  ... 


of  the  primary  simultaneous  sampling  rate  X. 

The  subchannels  are  then  sampled  and  ordered  such  that: 

•  The  highest  sample  rate  1  *X  subchannel(s)  appear  in  every  simultaneous  sample; 


The 


The 


r  i  x 


(1 


*  X  subchannel(s)  appear  in  every  2nd  simultaneous  sample; 


—  *  X  subchannel(s)  appear  in  every  4th  simultaneous  sample; 

v4  ) 


. . .  and  so  on  until  all  the  subchannels  are  sampled,  resulting  in  a  complete  sampling 
schedule  of  all  subchannels  described  by  the  CSDWs.  In  doing  so,  the  total  number  of 
simultaneous  samples  (not  the  total  number  of  samples)  will  equal  the  denominator  of  the 
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smallest  sampling  factor  and  all  subchannels  will  be  sampled  in  the  last  simultaneous 
sample. 

For  example,  a  packet  with  six  subchannels  with  sampling  factors  Vi,  1/8,  1,  Vi,  1,  and  1/8 
respectively  will  yield  a  sampling  sequence  within  the  data  packet  as: 


Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 
Simultaneous  Sample 


1:  Subchannel  3 

1:  Subchannel  5 

2:  Subchannel  1 

2:  Subchannel  3 

2:  Subchannel  4 

2:  Subchannel  5 

3:  Subchannel  3 

3:  Subchannel  5 

4:  Subchannel  1 

4:  Subchannel  3 

4:  Subchannel  4 

4:  Subchannel  5 

5:  Subchannel  3 

5:  Subchannel  5 

6:  Subchannel  1 

6:  Subchannel  3 

6:  Subchannel  4 

6:  Subchannel  5 

7:  Subchannel  3 

7:  Subchannel  5 

8:  Subchannel  1 

8:  Subchannel  2 

8:  Subchannel  3 

8:  Subchannel  4 

8:  Subchannel  5 

8:  Subchannel  6 


Notice  that  the  denominator  of  the  smallest  sampling  factor  defines  the  number  of 
simultaneous  samples  within  the  packet  (in  this  example,  8);  however,  the  total  number 
of  samples  within  the  sampling  schedule  does  not  have  to  equal  the  number  of 
simultaneous  samples  (in  this  example,  26).  Also  notice  that  all  subchannels  are  sampled 
during  the  last  simultaneous  sample.  The  order  of  the  subchannel  samples  in  each 
simultaneous  sample  is  ascending  by  subchannel  number. 

Any  number  of  complete  sampling  schedules  may  be  placed  within  a  packet  so  that  the 
maximum  packet  length  is  not  exceeded. 


(1)  Unpacked  Mode.  In  unpacked  mode,  packing  is  disabled  and  each  sample  is 

padded  with  the  number  of  bits  necessary  to  align  each  word  with  the  next  16-bit 
boundary  in  the  packet.  Four  pad  bits  are  added  to  12-bit  words,  eight  pad  bits  are 
added  to  8-bit  words,  etc.  All  pad  bits  shall  equal  zero. 
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NOTE/& 

Samples  less  than  8  bits  go  into  a  16-bit 

/ 

word  boundary. 

To  illustrate  msb  padding,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  msb  padding  have  the  form  shown  in  Table  1 1-20. 


Table  11-20.  Analog  Data  Packet-Unpacked  Mode,  msb  Padding 

msb  lsb 

15 _ 0 

Packet  Header _ 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel- Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  31-16) 


Channel-Specific  Data  Word,  Subchannel  M  (Bits  15-0) 


Channel- Specific  Data  Word,  Subchannel  M  (Bits  31-16) 


4  Pad  Bits 

Sample  1,  12  Data  Bits 

4  Pad  Bits 

Sample  2,  12  Data  Bits 

4  Pad  Bits 

Sample  3,  12  Data  Bits 

4  Pad  Bits 

Sample  N,  12  Data  Bits 

Packet  Trailer 

To  illustrate  lsb  packing,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  lsb  padding  have  the  form  shown  in  Table  11-21. 

Table  11-21.  Analog  Data  Packet-Unpacked  Mode,  lsb  Padding 

msb 

15 _ 

Packet  Header 

Channel- Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  2  (Bits  31-16) 


Channel-Specific  Data  Word,  Subchannel  M  (Bits  15-0) 


lsb 

0 
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Channel- Specific  Data  Word,  Subchannel  M  (Bits  31-16) 

Sample  1,12  Data  Bits 

4  Pad  Bits 

Sample  2,  12  Data  Bits 

4  Pad  Bits 

Sample  3,  12  Data  Bits 

4  Pad  Bits 

Sample  N,  12  Data  Bits 

4  Pad  Bits 

Packet  Trailer 

(2)  Packed  Mode.  In  packed  mode,  packing  is  enabled  and  padding  is  not  added  to 
each  data  word;  however,  if  the  number  of  bits  in  the  packet  are  not  an  integer 
multiple  of  16,  then  Y  filler  bits  will  be  used  to  msb  fill  the  last  data  word,  forcing 
alignment  on  a  16-bit  boundary.  The  value  of  Y  is  16  minus  the  integer  remainder 
of  L,  the  total  number  of  data  bits  in  the  packet,  divided  by  16  and  is 
mathematically  expressed  as: 

Y=  16-(MODULUS{L,16}). 

To  illustrate  msb  padding,  given  M  analog  subchannels  mapping  into  N  samples  for 
the  special  case  of  all  samples  having  bit  lengths  of  12  bits,  the  resultant  analog 
packets  with  padding  bits  at  the  end  of  the  Nth  sample  have  the  form  shown  in 
Table  11-22. 


Table  11-22.  Analog  Data  Packet-Packed  Mode  Packet 

msb 

15 

lsb 

0 

Packet  Header  ; 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  1  (Bits  31-16) 

Channel- Specific  Data  Word,  Subchannel  2  (Bits  15-0) 

Channel-Specific  Data  Word,  Subchannel  2  (Bits  31-16) 

Channel-Specific  Data  Word,  Subchannel  M  (Bits  15-0) 

Channel- Specific  Data  Word,  Subchannel  M  (Bits  31-16) 

Sample  2  (Bits  3-0) 

Sample  1  (Bits  11-0) 

Sample  3  (Bits  7-0) 

Sample  2  (Bits  11-4) 

Y  Padding  Bits 

Sample  N  (Bits  11-0) 

Packet  Trailer 
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11.2.6  Discrete  Data  Packets 

1 1.2.6. 1  Discrete  Data  Packets,  Format  0. 

Reserved. 

11.2.6.2  Discrete  Data  Packets,  Format  1 

A  packet  with  discrete  data  has  the  basic  structure  shown  in  Table  11-23.  Note  that  the 
width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely  intended  to 
represent  relative  placement  of  data  in  the  packet.  One  to  32  discrete  states  may  be  recorded  for 
each  event. 

Table  11-23.  General  Discrete  Data  Packet,  Format  1 

Packet  Header _ 

Channel- Specific  Data 
Intra-Packet  Header  for  Event  1 
Event  1  States 

Intra-Packet  Header  for  Event  2 
Event  2  States 


Intra-Packet  Header  for  Event  N 
Event  N  States 
Packet  Trailer 


a.  Discrete  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  discrete 
packet  begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-27. 


msb 

31 

8 

7 

3 

2 

lsb 

0 

RESERVED 

LENGTH 

MODE 

Figure  11-27.  Discrete  Packet  Channel  Data  Word 


•  Reserved.  Bits  31-8  are  reserved. 

•  Length.  Bits  7-3  indicate  a  binary  value  representing  the  number  of  bits  in  the  event. 
The  value  of  zero  indicates  32  bits. 

•  Mode.  Bits  2-0  indicate  the  mode  of  accessing  the  discrete  data. 

o  Bit  0:  indicates  the  record  state. 

0  =  discrete  data  is  recorded  when  the  state  changes 
1  =  discrete  data  is  recorded  on  a  time  interval  basis 

o  Bit  1:  indicates  the  alignment  of  the  data. 

0  =  lsb 
1  =  msb 

o  Bit  2:  reserved. 
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b.  Discrete  Data.  After  the  channel- specific  data,  discrete  data  (Figure  11-28)  is  inserted  in 
the  packet.  Discrete  data  are  described  as  events.  Each  event  includes  the  event  state  for 
each  discrete  input  and  the  corresponding  intra-packet  time.  The  event  state  is  a  32-bit 
word  that  provides  the  logical  state  of  each  discrete  input. 


msb 

31 

30 

1 

lsb 

0 

D31 

D30  ... 

Dl 

DO 

Figure  1 1-28.  Discrete  Data  Format 


•  Discrete  Event  Bits.  Bits  31-0  indicate  the  states  of  the  discrete  event  bits. 

Bit  31:  indicates  discrete  31  (D31)  state. 

0  =  discrete  3 1  is  at  state  0 
1  =  discrete  3 1  is  at  state  1 

Bit  30:  indicates  discrete  30  (D30)  state. 

0  =  discrete  30  is  at  state  0 
1  =  discrete  30  is  at  state  1 

Bit  1:  indicates  discrete  1  (Dl)  state. 

0  =  discrete  1  is  at  state  0 
1  =  discrete  1  is  at  state  1 

Bit  0:  indicates  discrete  0  (DO)  state. 

0  =  discrete  0  is  at  state  0 
1  =  discrete  0  is  at  state  1 

c.  Discrete  Event  Intra-Packet  Header.  All  discrete  events  shall  include  an  IPH  consisting 
of  an  IPTS  only,  which  is  inserted  immediately  before  the  discrete  event.  The  length  of 
the  IPH  is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  arranged  in  the  sequence 
shown  in  Figure  11-29. 

msb 

_31 _ 

Time  (LSLW) 

Time  (MSLW) 

Figure  1 1-29.  Discrete  Event  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  discrete  event. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values: 

(1)  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  discrete  event  with  bits 
31  to  16  in  the  second  long  word  zero  filled;  or 

(2)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit  of  the  discrete 
event.  The  discrete  data  packet  format  is  presented  in  Table  11-24. 


lsb 

0 
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Table  11-24.  Discrete  Data  Packet  Format 

msb  lsb 

15  0 

Packet  Fleader 

Channel-Specific  Data  (Bits  15-0) 

Channel- Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Event  1  (Bits  63-48) 

States  for  Event  1  (Bits  15-0) 

States  for  Event  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Event  N  (Bits  63-48) 

States  for  Event  N  (Bits  15-0) 

States  for  Event  N  (Bits  31-16) 

Packet  Trailer 

11.2.7  Computer-Generated  Data  Packets 

Packets  with  computer-generated  data  have  the  basic  structure  shown  in  Table  11-25. 
Formats  0,  1,2,  and  3  are  used  to  add  information  packets  to  recorded  data.  This  information 
contains  annotation  data,  setup  records,  events,  or  index  information  for  the  data  that  has  been 
recorded.  The  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  drawing  is  merely 
intended  to  represent  relative  placement  of  data  in  the  packet. 


NOTE 


y 


Computer-generated  data  is  defined  as  non-extemal  data  or  data  generated 
within  the  recorder.  After  the  CSDW,  the  computer-generated  data  is 
inserted  in  the  packet.  The  organization  and  content  of  the  computer¬ 
generated  data  is  determined  by  the  specific  format  type. 


Table  11-25.  General  Computer-Generated  Data  Packet  Format 

Packet  Fleader _ 

Channel-Specific  Data _ 

Computer  Generated  Data 
Packet  Trailer 


1 1.2.7. 1  Computer-Generated  Data  Packets  Format  0,  User-Defined 

Format  0  enables  the  insertion  of  user-defined  computer-generated  data.  Data  shall  not 
be  placed  in  packets  of  this  type  if  the  data  type  is  already  defined  within  this  standard  nor  shall 
data  be  inserted  in  this  packet  if  it  is  directly  generated  from  an  external  input  to  the  recorder. 
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•  Format  0  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  0 
packet  begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-30. 

•  Reserved.  Bits  31-0  are  reserved, 
msb 

_31 _ 

RESERVED 

Figure  1 1-30.  Computer-Generated  Format  0  Channel-Specific  Data  Word 


lsb 

0 


NOTE 


y 


For  this  format,  bits  31-0  are  declared  reserved; 
however,  they  are  considered  as  “User”  or 
“Application”  defined. 


1 1.2. 7. 2  Computer-Generated  Data  Packets  Format  1,  Setup  Records 

Format  1  defines  a  setup  record  that  describes  the  hardware,  software,  and  data  channel 
configuration  used  to  produce  the  other  data  packets  in  the  file.  The  organization  and  content  of 
a  Format  1  setup  record  is  indicated  in  the  CSDW  FRMT  field. 

A  single  setup  record  may  span  multiple  consecutive  packets.  When  spanning  multiple 
packets,  the  sequence  counter  shall  increment  in  the  order  of  segmentation  of  the  setup  record, 
77+1. 

a.  Format  1  Channel- Specific  Data  Word.  The  packet  body  portion  of  each  Format  1  packet 
begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-31. 


msb 

31 

10 

9 

8 

7 

lsb 

0 

RESERVED 

FRMT 

SRCC 

RCCVER 

Figure  11-31.  Computer-Generated  Format  1  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-10  are  reserved. 


•  FRMT.  Bit  9  is  the  setup  record  format. 


0  =  Setup  record  IAW  Chapter  9  ASCII  Format 
1  =  Setup  record  IAW  Chapter  9  XMF  Format 


NOTE 


y 


It  is  not  permissible  to  have  both  ASCII  and  XMF 
Chapter  9  TMATS  attributes  in  the  same  session 
(e.g.,  recording). 


•  Setup  Record  Configuration  Change  (SRCC).  Bit  8  indicates  if  the  recorder 
configuration  contained  in  the  previous  setup  record  packet(s)  of  the  current 
recording  session  (defined  as  .RECORD  to  .STOP)  has  changed. 

0  =  Setup  record  configuration  has  not  changed 
1  =  Setup  record  configuration  has  changed 


11-44 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


NOTE 


When  a  setup  record  configuration  change  has  taken  place,  bit  8  (SRCC) 
shall  be  set  to  1  and  the  new  setup  record  packet  will  be  committed  to  the 
stream  prior  to  any  new  or  changed  data  packets  being  committed  to  the 
stream.  The  next  setup  record  packet(s)  committed  to  the  stream,  if  not 
changed  from  this  new  setup  record,  shall  clear  the  SRCC  bit  to  0. 


NOTl^g; 

Prior  to  the  new  setup  record  being  committed  to  the 
stream,  a  setup  record  configuration  change  event 
packet  shall  be  inserted  into  the  stream. 

NOTI^g, 

Each  new  setup  record  packet  must  adhere  to  all 
applicable  setup  record  requirements  including,  but  not 
limited  to,  the  minimum  required  TMATS  attributes. 

•  RCC  106  Version  (RCCYER).  Bits  7-0  specify  which  RCC  release  version  applies 
and  to  which  the  following  recorded  data  complies  with.  The  value  shall  be 
represented  by  the  following  bit  patterns. 

0x00  through  0x06  =  Reserved 

0x07  =  RCC  106-07 

0x08  =  RCC  106-09 

0x09  =  RCC  106-11 

OxOA  =  RCC  106-13 

OxOB  =  RCC  106-15 

OxOC  =  RCC  106-17 

OxOD  through  OxFF  =  Reserved 

Individual  Chapter  1 1  data  types  and  their  format/content  compliance  and 
applicability  with  the  RCC  release  version  are  defined  in  Subsection  11.2.1.1  item  e. 

Note  that  this  field  was  known  as  “CHI  OVER”  in  RCC  versions  106-04  through  106- 
15,  where  it  was  described  in  Chapter  10  Subsection  10.6.7.2. 

1 1.2. 7. 3  Computer-Generated  Data  Packets  Format  2,  Recording  Event 

Format  2  defines  a  “Recording  Event”  packet  that  contains  the  occurrence  and 
information  of  one  or  more  individual  events  that  have  been  defined  within  the  Format  1  setup 
record  IAW  “Recording  Events”  attribute.  If  the  recording  events  information  is  larger  than  the 
maximum  packet  size  of  512  KB,  the  recording  events  information  may  be  contained  in  multiple 
packets  using  the  major  packet  header  sequence  number. 

Events  associated  with  the  .EVENT  command  defined  in  Chapter  6  Subsection  6.2.4.13 
can  only  be  directly  accessed  from  the  acquisition  system  itself  (e.g.,  recorder  system)  and  are 
not  contained  within  the  output  or  recorded  data.  This  does  not  preclude  defining  an  event 
driven  by  the  .EVENT  command  to  also  be  defined  within  the  recording  event  setup  record 
information  and  placed  in  the  appropriate  event  entry  within  an  event  packet.  The  .EVENT 
command  and  the  “Recording  Event”  packets  will  not  be  directly  linked  in  this  standard  and  any 
linking  between  the  two  will  be  an  implementation  of  this  standard  within  a  recorder. 
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NOTE  ^ 

It  is  not  the  intent  for  the  event  packets  within  the 

r 

data  to  be  directly  coupled  with  recorder  events  per 

the  .EVENT  command  in  Chapter  6  Subsection 

6.2.4.13. 

a.  Event  Packet  Location.  Recording  event  packets  may  be  placed  at  any  location  within 
the  recording  after  the  first  time  data  packet  and  before  the  last  root  index  packet.  This 
may  be  at  the  time  each  event  occurs,  after  multiple  events  have  occurred,  or  at  an 
interval  of  time  or  packets.  The  complete  event  log  of  a  recording  (defined  in  Subsection 
11.2.7.3  item  c)  is  constituted  by  the  contents  of  all  event  packets  in  a  recording 
concatenated  in  order  of  which  the  event(s)  occurred  in  time. 


NOTE 

Index  packets  will  be  enabled  if  recording  event 

/r 

packets  are  enabled.  Note  that  Index  packets  are  only 

r 

meaningful  if  a  Chapter  10  file  is  being  used  to  record 

packets. 

b.  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  2  packet  begins 
with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-32. 


msb 

lsb 

31 

30 

12 

11 

0 

IPDH 

RESERVED 

REEC 

Figure  11-32.  Computer-Generated  Format  2  Channel-Specific  Data  Word 


•  Recording  Event  Intra-Packet  Data  Header.  Bit  31  indicates  the  presence  of  the 
IPDH. 

0  =  Recording  event  IPDH  not  present 
1  =  Recording  event  IPDH  present 

•  Reserved.  Bits  30-12  are  reserved. 

•  Recording  Event  Entry  Count  (REEC).  Bits  11-0  are  an  unsigned  binary  that 
identifies  the  count  of  recording  event  entries  included  in  the  packet. 


c.  Event  Period  of  Capture.  The  event  period  of  capture  (Figure  11-33)  is  defined  to 
encompass  the  events  occurring  from  the  time  a  .RECORD  command  (Chapter  6, 
Subsection  6.2.2.31)  is  issued  (if  it  is  the  first  recording)  until  the  time  a  .STOP  command 
(Chapter  6,  Subsection  6. 2. 3. 9)  is  issued.  If  there  is  a  previous  recording,  the  period  of 
capture  is  described  as  encompassing  those  events  that  occur  from  the  previous 
recording’s  .STOP  command  until  the  .STOP  command  of  the  current  recording.  This 
ensures  that  any  events  that  occurred  between  recordings  will  be  captured  and  will 
include  special  indicators  that  the  event  occurred  between  .STOP  and  .RECORD 
commands. 
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Priority  conditions  and  event  limit  counts  are  defined  in  the  setup  record  attributes  for 
each  defined  event.  The  ability  to  put  finite  limits  on  events  during  periods  of  capture 
precludes  overflowing  buffers  or  media  capacities.  These  priority  conditions  and  event 
limit  counts  are  as  follows. 


Priority  1 

The  defined  event  will  always  be  captured  during  and  in  between 
recordings. 

Priority  2 

The  defined  event  will  always  be  captured  during  recordings  and  up  to 
a  limit  count  between  recordings. 

Priority  3 

The  defined  event  will  always  be  captured  during  recordings  and  not 
captured  between  recordings. 

Priority  4 

The  defined  event  will  be  captured  up  to  a  limit  count  during 
recordings  and  between  recordings. 

Priority  5 

The  defined  event  will  be  captured  up  to  a  limit  count  for  each  defined 
event  during  recordings  and  not  captured  between  recordings. 

Event  Condition  of  Capture.  Event  trigger  mode  conditions  during  the  event  period  of 
capture  are  defined  in  the  setup  record  attributes  for  each  defined  event.  These 
MEASUREMENT  DISCRETE,  MEASUREMENT  LIMIT,  or  MEASUREMENT 
CHANGE  trigger  mode  conditions  are  as  follows. 

Mode  1: 

Capture  MEASUREMENT  DISCRETE  event  at  each  On  (1)  and  Off 
(0)  mode  transition  sampling. 

Mode  2: 

Capture  MEASUREMENT  DISCRETE  event  at  each  On  (1)  mode 
transition  sampling. 

Mode  3: 

Capture  MEASUREMENT  DISCRETE  event  at  each  Off  (0)  mode 
transition  sampling. 

Mode  4: 

Capture  MEASUREMENT  LIMIT  event  at  each  high  and  low  value 
transition  sampling. 

Mode  5: 

Capture  MEASUREMENT  LIMIT  event  at  each  high  value  transition 
sampling. 
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Mode  6:  Capture  MEASUREMENT  LIMIT  event  at  each  low  value  transition 
sampling. 


Mode  7:  Capture  MEASUREMENT  CHANGE  event  on  each  change  of  value 
from  the  previous  value. 


NOTE 


If  Event  Type  is  MEASUREMENT  DISCRETE,  MEASUREMENT  LIMIT, 
or  MEASUREMENT  CHANGE,  the  trigger  measurement  must  be  fully 
described  using  the  setup  record  attributes  for  PCM,  bus,  analog,  or  discrete 
channels.  The  trigger  measurement  source  and  measurement  name  shall  be 
identified  in  the  event  definition. 


e.  Event  Initial  Capture.  Event  initial  capture  conditions  are  defined  in  the  setup  record 
attributes  for  each  defined  event.  This  determines  if  an  event  will  be  captured  initially 
prior  to  the  transition  mode  set  for  the  event  if  the  transition  has  already  occurred  prior  to 
the  event  period  of  capture. 

For  a  Mode  7  capture  of  a  MEASUREMENT  CHANGE  event,  there  shall  be  an  option 
for  an  initial  value  in  the  setup  record  that  does  not  generate  an  event  but  each  successive 
value  change  from  this  initial  value  shall  generate  an  event.  Event  limit  counts  for  mode 
7  shall  be  valid  on  the  number  of  events  generated  based  on  successive  value  changes 
from  each  previous  value. 

f.  Event  Trigger  Measurement  Description.  If  Event  Type  is  MEASUREMENT 
DISCRETE,  MEASUREMENT  LIMIT,  or  MEASUREMENT  CHANGE,  the  event 
trigger  measurement  must  be  fully  described  using  the  setup  record  attributes  for  PCM, 
bus,  analog,  or  discrete  channels.  This  shall  include  at  a  minimum  the  following 
attributes  for  the  trigger  measurement. 

(1)  Measurement  source  (via  data  link  name) 

(2)  Measurement  name 

(3)  Applicable  measurement  value  definition  or  bit  mask 

(4)  High  measurement  value  (if  MEASUREMENT  LIMIT  at  or  above  the  high  limit  is 
used  to  trigger  the  event) 

(5)  Low  measurement  value  (if  MEASUREMENT  LIMIT  at  or  below  the  low  limit  is 
used  to  trigger  the  event) 

(6)  (Optional)  Initial  measurement  value  (if  MEASUREMENT  CHANGE  is  used  to 
trigger  the  event) 

(7)  Applicable  measurement  name  engineering  unit  conversion 

g.  Recording  Event  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
recording  event  entry  as  follows. 

(1)  The  48-bit  RTC  that  corresponds  to  the  event  entry  with  bits  31  to  16  in  the  second 
long  word  zero-filled.  For  event  types  that  are  MEASUREMENT  DISCRETE  or 
MEASUREMENT  LIMIT,  the  time  tag  will  correspond  to  the  data  packet  timing 
mechanism  containing  the  trigger  measurement.  This  will  either  be  the  packet 
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header  RTC  value  or,  if  enabled,  the  IPTS  -  whichever  most  accurately  provides  the 
time  the  event  occurred;  or 

(2)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  event  entry.  For  event 
types  that  are  MEASUREMENT  DISCRETE  or  MEASUREMENT  LIMIT,  the 
time  tag  will  correspond  to  the  data  packet  timing  mechanism  containing  the  trigger 
measurement.  This  will  either  be  the  packet  secondary  header  or,  if  enabled  and 
using  an  absolute  time  value,  the  IPTS  -  whichever  most  accurately  provides  the 
time  the  event  occurred. 

h.  (Optional)  Recording  Event  Intra-Packet  Data  Header.  These  8  bytes  contain  the 
absolute  time  of  the  event  occurrence.  The  time  source  and  format  shall  be  derived  from 
the  Time  Data  Packet,  Format  1.  Unused  high-order  bits  will  be  zero-filled  as  needed, 
depending  on  the  time  type  of  the  time  data  packet.  The  format  of  the  recording  event 
IPH  is  presented  in  Figure  11-34. 

msb 

_31 _ 

Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

_ (Optional)  Intra-Packet  Data  Header  (LSLW) _ 

(Optional)  Intra-Packet  Data  Header  (MSLW) 

Figure  1 1-34.  Recording  Event  Intra-Packet  Header 

i.  Event  Packet  Entry  Format.  Table  11-26  and  Figure  11-35  present  the  general  recording 
event  packet  format  and  recording  event  entry  layout. 


Table  11-26.  General  Recording  Event  Packet  Format 

Packet  Header 

(Optional)  Packet  Secondary  Header 

Channel-Specific  Data 

Intra-Packet  Time  Stamp  for  Event  1 

(Optional)  Intra-Packet  Data  Header  for  Event  1 

Recording  Event  1 

Intra-Packet  Time  Stamp  for  Event  2 

(Optional)  Intra-Packet  Data  Header  for  Event  2 

Recording  Event  2 

Intra-Packet  Time  Stamp  for  Event  N 

(Optional)  Intra-Packet  Data  Header  for  Event  N 

Recording  Event  N 

Packet  Trailer 

lsb 

0 
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msb 

31  29 

28 

27 

12 

11 

lsb 

0 

RESERVED 

EO 

EVENT  COUNT 

NUMBER 

Figure  1 1-35.  Recording  Event  Entry  Layout 


•  Reserved.  Bits  31-29  are  reserved  for  future  growth  and  shall  be  zero-filled. 

•  Event  Occurrence  (EQ).  Bit  28  indicates  Event  Occurrence  State. 

0  =  Indicates  the  event  occurred  after  the  .STOP  command  and  before  the 
.RECORD  command. 

1=  Indicates  the  event  occurred  after  the  .RECORD  command  and  before  the 
.STOP  command. 

•  Event  Count.  Bits  27-12  represent  an  unsigned  binary  that  identifies  the  count  of  up 
to  65,535  occurrences  of  an  individually  defined  event  (as  defined  by  Event  Number 
in  the  following  paragraph).  Event  occurrence  counts  shall  begin  at  0x0  for  the  first 
occurrence  of  an  individual  event  type  (identified  by  the  event  number).  The  event 
count  can  roll  over  to  0x0  and  begin  to  count  up  again.  The  event  count  applicability 
is  for  each  event  period  of  capture  as  defined  in  Subsection  11.2.7.3  item  c.  The 
event  count  shall  start  from  0x0  at  the  beginning  of  each  event  period  of  capture 
incrementing  at  n+Oxl  to  OxFFFF  for  each  event  occurrence.  If  the  event  count 
reaches  OxFFFF  within  the  event  period  of  capture  it  shall  roll  over  to  0x0. 

•  Event  Number.  Bits  11-0  represent  an  unsigned  binary  that  identifies  4096  individual 
events  types  defined  in  the  corresponding  setup  record  recording  event  number.  The 
event  number  shall  begin  at  0x0  for  the  first  event  type  defined  in  the  setup  record 
and  increment  n+ 1  for  the  next  event  type  defined  in  the  setup  record. 


11.2.7.4 


Computer-Generated  Data  Packets  Format  3,  Recording  Index 


NOTE 


y 


The  Recording  Index  mechanism  is  only  meaningful  in 
the  context  of  a  Chapter  10  system,  and  is  undefined 
where  Chapter  1 1  packets  are  being  streamed. 


This  defines  an  index  packet  for  an  individual  recording  file  used  for  direct  access  into 
the  recording  file.  Recording  index  packets  will  be  enabled  when  recording  event  packets  are 
enabled.  There  are  two  types  of  index  packets. 


Root  Index  Packets.  These  packets  contain  zero-based  byte  offset  entries  that  are  the 
beginning  of  node  index  packets.  The  last  entry  will  be  an  offset  to  the  beginning  of 
the  previous  root  index  packet  in  its  chain  if  there  is  more  than  one  root  index  packet, 
or  to  the  beginning  of  the  root  index  packet  itself,  if  this  root  index  packet  is  either  the 
first  root  index  packet  of  the  recording  or  the  only  root  index  packet. 


NOTE 


y 


Root  index  packets  shall  not  contain  filler  in  the 
packet  trailer  and  shall  contain  a  32-bit  data 
checksum  in  the  packet  trailer. 
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NOTE 

Each  recording  file  with  indexes 

/ 

enabled  shall  have  at  a  minimum 

one  root  index  type  packet. 

•  Node  Index  Packets.  These  packets  contain  node  item  structures  containing 
information  about  the  location  of  data  packets  throughout  the  recording. 


NOTE 


At  a  minimum,  an  index  entry  shall  exist  for  each  time  data 
packet  in  the  recording  and,  at  a  minimum,  an  index  entry 
shall  exist  for  each  recording  event  packet  in  the  recording. 


NOTE 


If  the  recording  index  type  uses  a  count  rather  than  time,  the  time  data  packets 
and  computer-generated  data  packets  are  not  included  in  the  count  interval. 

-If  the  recording  index  type  uses  a  time  rather  than  count,  the  time  data 
packets  are  not  included  in  the  time  interval.  If  the  time  count  value  coincides 
with  the  time  packet  rate,  then  one  index  entry  shall  be  created. 


NOTE 


If  the  recording  indexes  are  enabled  the  Computer- 
Generated  Data  Packet,  Format  1  setup  record  count 
or  time  interval  value  cannot  be  zero. 


a. 


Recording  Index  Packet  Location.  If  indexes  are  enabled,  a  root  index  packet  (Figure 
11-36)  will  be  the  last  packet  in  any  recording  file.  More  than  one  root  index  type  packet 
may  be  created  and  may  be  located  within  the  recording.  Root  index  packets  are  not 
required  to  be  contiguous.  Node  index  types  may  be  placed  at  any  location  within  the 
recording  after  the  first  time  data  packet  and  before  the  last  root  index  packet.  This  may 
be  at  an  interval  of  time  or  packets.  If  indexes  are  based  on  a  time  interval,  the  time 
interval  shall  be  referenced  to  and  based  on  10  MHz  RTC  counts.  When  a  time-based 
index  time  interval  expiration  takes  place  and  all  packet(s)  are  open  (not  generated),  the 
index  offset  and  time  stamp  will  be  based  on  the  first  of  the  opened  packets  generated. 
Packet  generation  and  packet  generation  time  shall  apply  per  the  definitions  in  Subsection 


11.2.1. 
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Channel  ID 


Data  Type 


Data  Packet  Offset 

\ 


Packet  Header 
CSDW 


File  Size  (Opt)  I 

IPH  \ 


Node  Entry  1 

IPH 


IPH 
Node  Entry  n 


V 


“Intra-Packet  Header”  (IPH) 
contains  a  Intra-Packet  Time 
Stamp  &  optional  Intra-Packet 
Data  Header 


“Root  Offset”  points  to  the 
previous  Root  Index  Packet  or 
to  itself  if  it  is  the  only  or  first 
Root  Index  Packet 


Setup  Record  Packet 


Time  Data  Packet 


* 


Beginning  of  Recording  Session 


Data  Packet 


Node  Index  Packet  1 


Data  Packet 


Time  Data  Packet 


Data  Packet 


Event  Packet 


Time  Data  Packet 


Data  Packet 


Data  Packet 


Root  Index  Packet  1 


Time  Data  Packet 


Node  Index  Packet  n 


Root  Index  Packet  n 


V 


Packet  Header 


End  of  Recording  Session 


'\ 

'\ 

3 


V 


CSDW  \ 
File  Size  (Opt)  \ 


IPH 


Node  Offset  1 


IPH 


IPH 

Node  Offset  n  \ 


IPH 

Root  Offset  \ 
Packet  Trailer  \ 


V 


Figure  1 1-36.  Format  Showing  Root  Index  Packet 


b.  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  3  packet  begins 
with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-37. 


msb 

31 

30 

29 

28 

16 

15 

lsb 

0 

IT 

FSP 

IPDH 

RESERVED 

INDEX  ENTRY  COUNT 

Figure  1 1-37.  Computer-Generated  Format  3  Channel-Specific  Data  Word 


•  Index  Type  (IT).  Bit  31  indicates  the  type  of  index  packet. 

0  =  Root  index 
1  =  Node  index 

•  File  Size  Present  (FSP).  Bit  30  indicates  if  the  file  size  at  the  time  the  index  packet 
was  created  is  present. 

0  =  File  size  not  present 
1  =  File  size  present 

•  Index  Intra-Packet  Data  Header.  Bit  29  indicates  the  presence  of  the  IPDH. 

0  =  Index  IPDH  not  present 
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1  =  Index  IPDH  present 


•  Reserved.  Bits  28-16  are  reserved. 


Index  Entry  Count.  Bits  15-0  indicate  the  unsigned  binary  value  of  the  number  of 
index  entries  included  in  the  packet.  An  integral  number  of  complete  index  entries 
will  be  in  each  packet. 


NOTE 


y 


The  IPDH  presence  once  set  by  bit  29 
shall  be  the  same  state  for  the  entire 
recording. 


c.  Recording  Index  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
recording  index  entry  as  follows. 

•  The  48-bit  RTC  that  corresponds  to  the  index  entry,  with  bits  31  to  16  in  the  second 
long  word  zero-filled.  For  node  index  packets  this  corresponds  to  the  first  bit  in  the 
packet  body  of  the  packet  associated  with  the  node  index  item;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item  g). 
The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  tag  shall  be  correlated  to  the  index  entry.  For  node  index  packets 
this  corresponds  to  the  first  bit  in  the  packet  body  of  the  packet  associated  with  the 
node  index  item. 

d.  (Optional)  Recording  Index  Intra-Packet  Data  Header.  These  8  bytes  contain  the  absolute 
time  of  the  index  entry.  The  time  source  and  format  shall  be  derived  from  the  Time  Data 
Packet,  Format  1 .  Unused  high-order  bits  will  be  zero-filled  as  needed,  depending  on  the 
time  type  of  the  time  data  packet.  Figure  11-38  presents  the  format  of  the  recording 
index  IPH. 

msb 

_31 _ 

Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

(Optional)  Intra-Packet  Data  Header  (LSLW) 

(Optional)  Intra-Packet  Data  Header  (MSLW) 

Figure  11-38.  Recording  Index  Intra-Packet  Header 

e.  Root  Index  Packet  Entry  Format.  A  root  index  packet  contains  a  node  index  offset  entry 
or  entries  using  the  format  shown  in  Table  11-27  and  Table  11-28. 

Table  11-27.  General  Recording  Root  Index  Packet 

Packet  Header _ 

(Optional)  Packet  Secondary  Header _ 

Channel- Specific  Data 
(Optional)  Root  Index  File  Size 
Intra-Packet  Time  Stamp  for  Node  Index  1 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1 _ 


lsb 

0 
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Node  Index  Offset  1 


Intra-Packet  Time  Stamp  for  Node  Index  N 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N 

Node  Index  Offset  N 

Intra-Packet  Time  Stamp  for  Root  Index 

(Optional)  Intra-Packet  Data  Header  for  Root  Index 

Root  Index  Offset 

Packet  Trailer 


Table  11-28.  Recording  Root  Index  Entry  Layout 

msb  lsb 

31  0 

(Optional)  File  Size  (LSLW) 

(Optional)  File  Size  (MSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  1  (LSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  1  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1  (MSLW) 

Node  Index  Offset  1  (LSLW) 

Node  Index  Offset  1  (MSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  N  (LSLW) 

Intra-Packet  Time  Stamp  for  Node  Index  N  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N  (MSLW) 

Node  Index  Offset  N  (LSLW) 

Node  Index  Offset  N  (MSLW)  ' 

Intra-Packet  Time  Stamp  for  Root  Index  (LSLW) 

Intra-Packet  Time  Stamp  for  Root  Index  (MSLW) 

(Optional)  Intra-Packet  Data  Header  for  Root  Index  (LSLW) 

(Optional)  Intra-Packet  Data  Header  for  Root  Index  (MSLW) 

Root  Index  Offset  (LSLW) 

Root  Index  Offset  (MSLW) 

•  (Optional)  Root  Index  File  Size.  These  8  bytes  are  an  unsigned  binary  that  identifies 
the  current  size  in  bytes  of  the  file  at  the  time  the  root  index  packet  was  created  and 
placed  into  the  recording.  This  value  should  be  the  same  as  the  root  index  offset. 

The  file  size  is  required  when  a  recording  is  split  across  multiple  media,  individual  or 
multiple  channels  are  split  from  the  original  recording  file,  or  time  slices  are  extracted 
from  the  original  recording.  In  all  cases  the  original  recording  file  size  will  allow 
recalculation  and/or  replacement  of  the  index  offsets  when  required. 
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•  Node  Index  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  node  index  packet  sync  pattern  (0xEB25)  begins. 

•  Root  Index  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  previous  root  index  packet  in  its  chain  begins,  if  there  is  more  than  one  root 
index  packet  or  to  itself,  if  it  is  the  first  or  only  root  index  packet. 


f.  Node  Index  Packet  Entry  Format.  A  node  index  packet  contains  an  index  entry  or  entries 
using  the  format  shown  in  Table  11-29  and  Figure  11-39. 


Table  11-29.  General  Recording  Node  Index  Packet 

Packet  Header 

(Optional)  Packet  Secondary  Header 

Channel- Specific  Data 

(Optional)  Node  Index  File  Size 

Intra-Packet  Time  Stamp  for  Node  Index  1 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  1 

Recording  Node  Index  1 

Intra-Packet  Time  Stamp  for  Node  Index  2 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  2 

Recording  Node  Index  2 

Intra-Packet  Time  Stamp  for  Node  Index  N 

(Optional)  Intra-Packet  Data  Header  for  Node  Index  N 

Recording  Node  Index  N 

Packet  Trailer 

msb 

lsb 

31  24 

23 

16 

15 

0 

Reserved 

Data  Type 

Channel  ID 

Data  Packet  Offset  (FSFW) 

Data  Packet  Offset  (MSFW) 

Figure  11-39.  Recording  Node  Index  Entry  Fayout 


•  (Optional)  Node  Index  File  Size.  These  8  bytes  are  an  unsigned  binary  that  identifies 
the  current  size  in  bytes  of  the  file  at  the  time  the  node  index  packet  was  created  and 
placed  into  the  recording.  This  value  should  be  the  same  as  the  node  index  offset. 

The  file  size  is  required  when  a  recording  is  split  across  multiple  media,  individual  or 
multiple  channels  are  split  from  the  original  recording  file,  or  time  slices  are  extracted 
from  the  original  recording.  In  all  cases  the  original  recording  file  size  will  allow 
recalculation  and/or  replacement  of  the  index  offsets  when  required. 

•  Channel  ID.  These  2  bytes  are  an  unsigned  binary  that  identifies  a  value  representing 
the  packet  channel  ID  for  the  data  packet  associated  with  this  node  index  item. 
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•  Data  Type.  This  byte  is  an  unsigned  binary  that  identifies  a  value  representing  the 
type  and  format  of  the  data  packet  associated  with  this  node  index  item. 

•  Data  Packet  Offset.  These  8  bytes  are  an  unsigned  binary  that  identifies  the  zero- 
based  byte  offset  from  the  beginning  of  the  recording  file  to  the  point  in  the  file  at 
which  the  data  packet  sync  pattern  (0xEB25)  begins  for  this  node  index  packet  item. 

1 1.2. 7. 5  Computer-Generated  Data  Packets  Format  4,  Streaming  Configuration  Records 

Format  4  is  used  to  report  the  active  streaming  or  recording  configuration  of  the  system. 
The  organization  and  content  of  a  Format  4  Streaming  Configuration  record  is  indicated  in  the 
CSDW  FRMT  field. 

A  single  Streaming  Configuration  record  may  span  multiple  packets.  When  spanning 
occurs,  no  other  Format  4  Computer-Generated  Data  Packet  shall  be  interspersed,  although  other 
packet  types  are  permitted  between  segments  of  a  Format  4  packet.  When  spanning  multiple 
packets,  the  segments  shall  be  output  in  order,  and  the  last  segment  shall  be  flagged  in  the 
CSDW. 

a.  Format  4  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  4  packet 
begins  with  the  CSDW,  which  is  formatted  as  shown  in  Figure  11-40. 


msb 

31 

16 

15 

14 

8 

7 

lsb 

0 

RESERVED 

FAST 

FRMT 

RCCVER 

Figure  11-40.  Computer-Generated  Format  4  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved. 

•  FRMT.  Bits  14-8  contain  the  streaming  configuration  record  format  according  to  the 
following  bit  patterns: 

000  0000  =  Complete  record  IAW  Chapter  9  ASCII  Format 
000  0001  =  Complete  record  IAW  Chapter  9  XMF  Format 
000  0010  =  Segmented  part  of  an  ASCII  Format  record 
000  0011  =  Segmented  part  of  an  XMF  Format  record 
000  0100  =  SHA2-256  Checksum 
000  0101  =  Currently  Selected  Channels 

•  FAST.  Bit  15  that  the  current  packet  is  the  last  packet  of  a  series  of  segmented 
packets.  Ignored  if  the  FRMT  bits  do  not  denote  a  segmented  record. 

0  =  The  current  packet  is  not  the  last  packet. 

1  =  The  current  packet  is  the  last  packet  in  a  segmented  series. 

•  RCC  106  Version  (RCCYER).  Bits  7-0  specify  which  RCC  release  version  applies 
and  to  which  the  following  recorded  data  complies  with.  The  value  shall  be 
represented  by  the  following  bit  patterns. 

0x00  through  OxOB  =  Reserved 

OxOC  =  RCC-106-17 

OxOD  through  OxFF  =  Reserved 
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Individual  Chapter  1 1  data  types  and  their  format/content  compliance  and 
applicability  with  the  RCC  release  version  are  defined  in  Subsection  11.2.1.1  item  e. 

b.  Full  or  Segmented  ASCII  or  XML  Format  Records.  Immediately  following  the  CSDW 
in  the  case  of  the  complete  or  segmented  versions  of  either  the  ASCII  or  XML  variants  of 
the  full  TMATS  configuration  record  shall  be  the  text  of  the  TMATS  record,  or  (if 
segmented)  the  text  that  immediately  sequentially  follows  the  last  character  of  the 
previous  segmented  part  of  the  TMATS  record. 

c.  SHA2-256  Checksum.  Immediately  following  the  CSDW  shall  be  32  bytes  containing 
the  binary  representation  of  the  256-bit  SHA2  checksum,  calculated  IAW  Chapter  6 
Subsection  6.2.3. 1  l.f.  This  structure  is  shown  in  Table  11-30.  Note  that  Subsection 
6.2.3. 1  l.f  and  the  Chapter  9  “GVSHA”  attribute  both  reference  hexadecimal 
representations  of  the  binary  value  used  in  this  record. 


Table  11-30.  SHA2-256  Checksum  Packet  Layout 

msb  lsb 

31  0 

Packet  Header 

Channel-Specific  Data  (Bits  31-0) 

Checksum  bits  255-224 

Checksum  bits  223-192 

Checksum  bits  191-160 

Checksum  bits  159-128 

Checksum  bits  127-96 

Checksum  bits  95-64 

Checksum  bits  63-32 

Checksum  bits  31-0 

Packet  Trailer 

To  avoid  confusion,  the  “big  endian”  format 
referenced  by  FIPS  180-2  shall  be  used.  Thus 
each  32  bit  portion  of  the  checksum  shown 
above  shall  be  treated  as  “big  endian”. 


d.  Currently  Selected  Channels.  Immediately  following  the  CSDW  shall  be  a  16-bit  count 
of  the  number  of  16-bit  words  that  follow,  with  each  following  word  providing  the 
channel  ID  of  a  channel  currently  selected  (or  enabled)  for  output.  This  structure  is 
shown  in  Table  11-31.  The  order  of  the  channels  in  the  body  of  the  record  is 
implementation-dependent . 

Table  11-31.  Currently  Selected  Channel  Layout 

msb  lsb 

15 _ 0_ 

Packet  Header _ 

Channel- Specific  Data  (Bits  15-0) 
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Channel- Specific  Data  (Bits  31-16) 


Number  of  Valid  Channels  to  follow 


Channel  ID  #1 


Channel  ID  #2 


Channel  ID  #n 


[  optional  filler  bytes  ] 


Packet  Trailer 


11.2.8  ARINC-429  Data  Packets 

11.2.8.1  ARINC-429  Data  Packets,  Format  0 

Data  shall  be  packetized  in  word  mode:  each  32-bit  word  of  an  ARINC-429  bus  shall  be 
preceded  by  an  IPH  containing  an  IPDH  only  with  an  identifier  (ID  word)  that  provides  type  and 
status  information.  The  IPH  does  not  contain  an  IPTS.  The  packet  time  in  the  packet  header  is 
the  time  of  the  first  ARINC  data  word  in  the  packet,  and  the  time  of  successive  ARINC  data 
words  is  determined  from  the  first  word  time  using  the  gap  times  in  the  ID  words  that  precede 
each  of  the  data  words.  Multiple  words  of  multiple  ARINC-429  buses  can  be  inserted  into  a 
single  packet.  The  resultant  packets  shall  have  the  following  format  as  shown  in  Table  11-32. 


Table  11-32.  ARINC-429  Data  Packet  Format 

msb  lsb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Word  1  Intra-Packet  Data  Header 

Word  1  Intra-Packet  Data  Header 

ARINC-429  Data  Word  1  (Bits  15-0) 

ARINC-429  Data  Word  1  (Bits  31-16) 

Word  2  Intra-Packet  Data  Header 

Word  2  Intra-Packet  Data  Header 

ARINC-429  Data  Word  2  (Bits  15-0) 

ARINC-429  Data  Word  2  (Bits  31-16) 

Word  N  Intra-Packet  Data  Header 

Word  N  Intra-Packet  Data  Header 

ARINC-429  Data  Word  N  (Bits  15-0) 

ARINC-429  Data  Word  N  (Bits  31-16) 

Packet  Trailer 

NOTE  /&, 

Time  tagging  of  ARINC-429  shall 

/r 

correspond  to  the  first  data  bit  of  the 

r 

packet. 
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a.  ARINC-429  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
ARINC-429  data  packet  shall  begin  with  a  CSDW  formatted  as  shown  in  Figure  11-41. 


msb 

lsb 

31 

16 

15 

0 

RESERVED 

MSGCOUNT 

Figure  11-41.  ARINC-429  Packet  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved 

•  Message  Count  (MSGCOUNT).  Bits  15-0  indicate  the  binary  value  of  the  number  of 
ARINC-429  words  included  in  the  packet. 

b.  Intra-Packet  Data  Header.  Bits  31-0  contain  the  ARINC-429  ID  word.  Each  ARINC- 
429  bus  data  word  is  preceded  by  an  ID  word  and  the  bit  definitions  are  as  shown  in 
Figure  11-42. 
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20 
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BUS 

FE 

PE 

BS 

R 

GAP  TIME 

Figure  1 1-42.  Intra-Packet  Data  Header  Format 


•  Bus.  Bits  31-24  indicate  a  binary  value  identifying  the  ARINC-429  bus  number 
associated  with  the  following  data  word.  The  first  bus  is  indicated  by  0.  A  maximum 
of  256  buses  can  be  placed  in  one  packet. 

•  Format  Error  (FE).  Bit  23  indicates  an  ARINC-429  foimat  error. 

0  =  No  format  error  has  occurred 
1  =  Format  error  has  occurred 

•  Parity  Error  (PE).  Bit  22  indicates  an  ARINC-429  parity  error. 

0  =  No  parity  error  has  occurred 
1  =  Parity  error  has  occurred 

•  Bus  Speed  (BS).  Bit  21  indicates  the  ARINC-429  bus  speed  the  data  is  from. 

0  =  Indicates  low-speed  ARINC-429  bus  (12.5  kHz) 

1  =  Indicates  high-speed  ARINC-429  bus  (100  kHz) 

•  Reserved  (R).  Bit  20  is  reserved. 

•  Gap  Time  (GAP  TIME).  Bits  19-0  contain  a  binary  value  that  represents  the  gap  time 
from  the  beginning  of  the  preceding  bus  word  (regardless  of  bus)  to  the  beginning  of 
the  current  bus  word  in  0. 1-ps  increments.  The  gap  time  of  the  first  word  in  the 
packet  is  GAP  TIME  =  0.  When  the  gap  time  is  longer  than  100  ms,  a  new  packet 
must  be  started. 

c.  ARINC-429  Packet  Data  Words.  The  data  words  shall  be  inserted  into  the  packet  in  the 

original  32-bit  format  as  acquired  from  the  bus. 
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11.2.9  Message  Data  Packets 


1 1.2.9. 1  Message  Data  Packets,  Format  0 

The  data  from  one  or  more  separate  serial  communication  interface  channels  can  be 
placed  into  a  message  data  packet  (Table  11-33). 


Table  11-33.  Message  Data  Packet  Format 

msb  lsb 

15 _ 0 

Packet  Header 

Channel- Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) _ 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

_ Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) _ 

Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  1  (Bits  31-16) 


Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  N  (Bits  31-16) 


Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Message  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  message 
data  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body  contains  several  short 
messages  (type:  complete)  or  one  segment  of  a  long  message  (type:  segmented). 

b.  Complete  Message  Channel-Specific  Data  Word.  The  CSDW  is  formatted  for  the 
complete  type  of  packet  body  as  shown  in  Figure  11-43. 
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31 

18 

17  16 
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RESERVED 

TYPE 

COUNTER 

Figure  1 1-43.  Complete  Message  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-18  are  reserved. 
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•  Type.  Bits  17-16  indicate  the  type  of  serial  packet. 

00  =  One  or  more  complete  messages 
01  =  Reserved 

10  =  Reserved 

11  =  Reserved 

•  Counter.  Bits  15-0  contain  a  binary  value  indicating  the  number  of  messages 
included  in  the  packet. 


c.  Segmented  Message  Channel-Specific  Data  Word.  The  CSDW  is  formatted  for  the 
segmented  type  of  packet  body  as  shown  in  Figure  11-44. 


msb 
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RESERVED 

TYPE 

COUNTER 

Figure  1 1-44.  Segmented  Message  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-18  are  reserved. 

•  Type.  Bits  17-16  indicate  the  type  of  serial  packet. 

00  =  Reserved 

01  =  Packet  is  a  beginning  of  a  long  message  from  a  single  source 

10  =  Whole  packet  is  the  last  part  of  a  long  message  from  a  single  source 

11  =  Whole  packet  is  a  middle  part  of  a  long  message  from  a  single  source 

•  Counter.  Bits  15-0  contain  a  binary  value  indicating  the  segment  number  of  a  long 
message.  The  number  must  start  with  1  and  must  be  incremented  by  one  after  each 
packet.  The  maximum  length  of  a  single  long  message  is  4  gigabytes  (combined  with 
the  16-bit  Message  Length  field;  see  description  in  item  d  below). 

d.  Message  Data  Intra-Packet  Header.  After  the  channel-specific  data,  message  data  is 
inserted  into  the  packet.  Each  message  is  preceded  by  an  IPH  that  has  both  an  IPTS  and 
an  IPDH  containing  a  message  ID  word.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96 
bits)  positioned  contiguously,  in  the  sequence  shown  in  Figure  11-45. 


Figure  11-45.  Message  Data  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  message  data. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

(3)  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  message  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 
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(4)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit  in  the  message. 


•  Intra-Packet  Data  Header.  The  IPDH  is  an  identification  word  (message  ID  word) 
that  precedes  the  message  and  is  inserted  into  the  packet  with  the  format  shown  in 
Figure  11-46. 
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DE 

FE 

SUBCHANNEL 

MESSAGE  LENGTH 

Figure  1 1-46.  Intra-Packet  Data  Header  Format 


•  Data  Error  (DE).  Bit  31  indicates  bad  data  bits  as  determined  by  parity,  checksums, 
or  cyclic  redundancy  check  words  received  with  the  data. 

0  =  No  data  error  has  occurred 
1  =  Data  error  has  occurred 

•  Format  Error  (FE).  Bit  30  indicates  a  protocol  error,  such  as  out-of- sequence  data  or 
length  errors. 

0  =  No  format  error 
1  =  Format  error  encountered 

•  Subchannel.  Bits  29-16  contain  a  binary  value  that  represents  the  subchannel  number 
belonging  to  the  message  that  follows  the  ID  word  when  the  channel  ID  in  the  packet 
header  defines  a  group  of  subchannels.  Zero  means  first  and/or  only  subchannel. 

•  Message  Length.  Bits  15-0  contain  a  binary  value  representing  the  length  of  the 
message  in  bytes  in)  that  follows  the  ID  word.  The  maximum  length  of  a  message 
(complete)  or  a  message  segment  (segmented)  is  64  KB. 


11.2.10  Video  Packets 

1 1.2.10.1  Video  Packets,  Format  0  (Moving  Picture  Experts  Group-2/H.264) 

Format  0  Moving  Picture  Experts  Group  (MPEG)-2/H.264  encoding  will  be  IAW 
Department  of  Defense  Motion  Imagery  Standards  Profile  (MISP)  Standard  9601. 6  The  MPEG- 
2/H.264  format  will  be  transport  streams  (TS)  per  MISP  Recommended  Practice  (RP)  0101.1. 7 
The  TS  will  be  encapsulated  at  a  constant  bit  rate  (CBR)  within  the  limits  of  MPEG-2  MP@ML 


6  Motion  Imagery  Standards  Board.  “Standard  Definition  Digital  Motion  Imagery,  Compression  Systems.”  STD 
9601  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26 
April  2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

7  Motion  Imagery  Standards  Board.  “Use  of  MPEG-2  System  Streams  in  Digital  Motion  Imagery  Systems.”  RP 
0101.1.  27  January  2011.  Superseded  by  MISB  ST  1402.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mil/misb/docs/rp/RP0101 . 1  .pdf. 
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and  H.264  MP@L3  specifications  per  MISP  Recommended  Practice  9720d8  for  further 
standardization  and  telemeter/transmission  requirements  of  the  video. 

These  MPEG-2/H.264  algorithm  features  are  combined  to  produce  an  encoded  video 
stream  that  will  be  encapsulated  in  Format  0  packets.  The  H.264  can  be  carried  over  the  MPEG- 
2  TSs  using  International  Telecommunications  Union/Telecommunication  Standardization 
Sector  (ITU-T)  Recommendation  H.222.09  for  MPEG2  TS  containment  for  MPEG4  advanced 
video  codec.  The  MISP  has  adapted  this  with  9720d  and  9701. 

The  TSs  are  limited  to  a  single  program  stream  (PS)  using  program  elementary  stream 
(PES)  packets  that  share  the  same  common  time  base.  A  TS  must  contain  the  program 
association  table  (PAT)  and  program  map  table  (PMT)  that  define  the  program  ID  (PID)  for  the 
program  clock  reference  (PCR)  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

A  packet  with  Format  0  MPEG-2/H.264  video  data  has  the  basic  structure  shown  in 
Table  11-34.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  This  figure 
is  merely  intended  to  represent  relative  placement  of  data  in  the  packet. 


Table  11-34.  General  MPEG-2/H.264  Video  Packet,  Format  0 

Packet  Header 

Channel-Specific  Data 

(Optional)  Intra-Packet  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Time  Header 

188-Byte  TS  Data 

(Optional)  Intra-Packet  Time  Header 

188-Byte  TS  Data 

Packet  Trailer 

a.  Video  Packet  Audio.  When  recording  video  using  Format  0,  if  audio  is  present  it  will  be 
inserted  into  the  TS  per  ISO/IEC  138 18-3 10  for  MPEG-2  and  ISO/IEC  14496-3 11  for 
H.264.  A  separate  analog  channel  to  specifically  record  audio  will  not  be  required  as 


8  Motion  Imagery  Standards  Board.  “Motion  Imagery  Systems  Matrix,  Standard  Definition  Motion  Imagery.”  RP 
9720d  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26 
April  2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

international  Telecommunications  Union  Telecommunication  Standardization  Sector.  Information  technology  - 
Generic  coding  of  moving  pictures  and  associated  audio  information:  Systems.  ITU-T  Rec. H.222.0  (06/12).  June 
2012.  May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at  http://www.itu.int/rec/T-REC- 
H.222.0/en. 

10  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology— Generic  coding  of  moving  pictures  and  associated  audio  information  --  Part  3,  Audio.  ISO/IEC  13818- 
3:1998.  Geneva:  International  Organization  for  Standardization,  1998. 

11  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  -  Coding  of  Audio-Visual  Objects  -  Part  3:  Audio.  ISO/IEC  14496-3  ed  4.0.  Updated  by  ISO/IEC 
14496-3:2009.  Retrieved  26  April  2017.  Available  for  purchase  at 

http://webstore.iec.ch/Webstore/webstore.nsf/ArtNum  PK/43306!opendocument&preview=l. 
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MPEG-2/H.264  supports  audio  insertion  into  the  TS.  By  combining  video  and  audio, 
recording  bandwidth  and  memory  capacity  will  be  increased. 


b.  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  Format  0 
packet  begins  with  the  CSDW,  formatted  as  shown  in  Figure  11-47. 
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Figure  11-47.  Video  Packet  Channel-Specific  Data  Word 


•  Embedded  Time  (ET).  Bit  31  indicates  if  embedded  time  is  present  in  the  MPEG-2 
video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 

MPEG-2  stream  embedded  time  if  utilized  will  be  IAW  MISP  Standard  9708 12  and 
Standard  9715 13.  Embedded  time  is  used  for  the  synchronization  of  core  MPEG-2 
data  when  extracted  from  the  Chapter  10  domain  (i.e.,  an  export  to  MPEG-2  files). 

•  Intra-Packet  Header.  Bit  30  indicates  if  IPTSs  are  inserted  before  each  transport 
packet. 

0  =  Intra-packet  times  not  present 
1  =  Intra-packet  times  present 

•  SCR/RTC  Sync  (SRS).  Bit  29  indicates  if  the  MPEG-2  SCR  is  RTC. 

0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC 
1  =  SCR  is  synchronized  with  the  10  MHz  RTC 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  time  source  referred  to  as  the  system  clock  reference  (SCR). 
Within  a  TS,  each  embedded  program  contains  its  own  PCR,  requiring  that  each 
Format  0-encoded  MPEG-2/H.264  TS  contains  only  a  single  program  allowing  each 
format  to  be  treated  in  a  similar  manner  using  a  single  global  clocking  reference. 

The  10  MHz  RTC  is  for  the  purposes  of  synchronizing  and  time-stamping  the  data 
acquired  from  multiple  input  sources.  For  input  sources  that  don’t  define  an  explicit 
timing  model  for  data  presentation,  superimposing  this  timing  model  can  be 
accomplished.  For  MPEG-2/H.264,  however,  an  explicit  synchronization  model 
based  on  a  27  MHz  clock  is  defined  for  the  capture,  compression,  decompression,  and 
presentation  of  MPEG-2/H.264  data.  In  order  to  relate  the  two  different  timing 
models,  the  MPEG-2/H.264  SCR/PCR  time  stamps  (if  enabled)  will  be  derived  from 


12  Motion  Imagery  Standards  Board.  “Imbedded  Time  Reference  for  Motion  Imagery  Systems.”  STD  9708  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April 
2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

13  Motion  Imagery  Standards  Board.  “Time  Reference  Synchronization.”  STD  9715  in  Motion  Imagery  Standards 
Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015.2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.iiga.mil/misb/docs/misp/MlSP64.pdf. 
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the  10-MHz  RTC  timing  reference  source  (by  generating  the  27 -MHz  MPEG- 
2/H.264  reference  clock  slaved  to  the  10-MHz  RTC). 

MPEG-2/H.264  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a 
33-bit  base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  +  SCR_ext 

where: 


SCR_base=  [(system_clock_frequency  *  t)  GOO]  MOD  233 

SCR_ext  =  [(system_clock_frequency  *  t)  /l]  MOD  300 

For  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10-MHz  RTC  using  the  equation: 

10-MHz  RTC  time  base  =  SCR  *  10/27  (rounded  to  nearest  integer) 

For  recording  periods  longer  than  this,  the  Format  0  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-2/H.264  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

•  Key-Fength- Value.  Bit  28  indicates  if  key-length-value  (KFV)  metadata  is  present  in 
the  MPEG-2  video  data. 

0  =  No  KFV  metadata  present 
1  =  KFV  metadata  is  present 


MPEG-2/H.264  stream  KFV  metadata,  if  utilized,  will  be  IAW  the  following  MISP 
documents: 

o  Standard  97 11 14 

o  Standard  97 12 15 

o  Standard  97 13 16 

o  Recommended  Practice  97 1 7 1 7 

o  Standard  0107.1. 18 


14  Motion  Imagery  Standards  Board.  “Intelligence  Motion  Imagery  Index,  Geospatial  Metadata.”  STD  9711  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April 
2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

15  Motion  Imagery  Standards  Board.  “Intelligence  Motion  Imagery  Index,  Content  Description...”  STD  9712  in 
Motion  Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April 
2017.  Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

16  Motion  Imagery  Standards  Board.  “Data  Encoding  Using  Key-Length- Value.”  STD  9713  in  Motion  Imagery 
Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

17  Motion  Imagery  Standards  Board.  “Packing  KLV  Packets  into  MPEG-2  Systems  Streams.”  RP  9717  in  Motion 
Imagery  Standards  Profile.  MISP  6.4.  4  October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April  2017. 
Available  at  http://www.gwg.nga.mil/misb/docs/misp/MISP64.pdf. 

18  Motion  Imagery  Standards  Board.  Bit  and  Byte  Order  for  Metadata  in  Motion  Imagery  Files  and  Streams.  STD 
107.1.  June  2011.  Updated  by  STD  107.2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.mi1/misb/docs/standards/ST0107.l.pdf. 
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•  Payload  (PL).  Bits  27-24  indicate  the  payload  type  within  the  MPEG-2  stream  per 
MISP  Xon2.19 

0000  =  MPEG-2  MP  @  ML 
0001  =  H.264  MP  @  L2.1 
0010  =  H.264  MP  @  L2.2 
0011  =  H.264  MP  @  L3 
0100-1 111=  Reserved. 

•  Byte  Alignment  (BA).  Bit  23  indicates  the  MPEG-2  data  payload  byte  alignment 
within  16-bit  words. 


0  =  Little-endian  as  referenced  in  Figure  11-48. 
1  =  Big-endian  as  referenced  in  Figure  11-49. 
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15 

lsb 

0 

TS  Sync  Byte  (Bits  0  to  7) 

TS  Data  (Bits  8  to  15) 

TS  Data  (Bits  16  to  23) 

TS  Data  (Bits  24  to  31) 

TS  Data  (Bits  1488  to  1495) 

TS  Data  (Bits  1496  to  1503) 

Figure  11-48.  Format  0  MPEG-2/H.264  Video  Frame  Format,  16-Bit 


Little-Endian  Aligned 


msb 

15 

lsb 

0 

TS  Data  (Bits  8  to  15) 

TS  Sync  Byte  (Bits  0  to  7) 

TS  Data  (Bits  24  to  31) 

TS  Data  (Bits  16  to  23) 

TS  Data  (Bits  1496  to  1503) 

TS  Data  (Bits  1488  to  1495) 

Figure  1 1-49.  Format  0  MPEG-2/H.264  Video  Frame  Format,  16-Bit  Big- 

Endian  (Native)  Aligned 


•  Reserved.  Bits  22-0  are  reserved. 

c.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  TS  sync  pattern.  The  length  of  the  IPH  is  fixed  at  8  bytes  (64 
bits)  positioned  contiguously,  in  Figure  11-50. 

msb  lsb 

_31 _ 0_ 

Time  (LSLW) _ 

Time  (MSLW) _ 

Figure  11-50.  Video  Packet,  Format  0  Intra-Packet  Header 


19  Motion  Imagery  Standards  Board.  “Xon2”.  Subsection  D-l. 2  in  Motion  Imagery  Standards  Profile.  MISP  6.4.  4 
October  2012.  Updated  by  MISP-2015. 2.  Retrieved  26  April  2017.  Available  at 
http://www.gwg.nga.  mil/mi  sb/docs/mi  sp/MI  S  P64 .  pdf . 


11-66 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual  TS 
packets.  First  long  word  (LSLW)  bits  31-0  and  second  long  word  (MSLW)  bits  31-0 
indicate  the  following  values. 

(5)  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  TS.  Bits  31  to  16  in  the 
second  long  word  (MSLW)  will  be  zero  filled;  or 

(6)  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item 
g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection 
11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of  the  TS. 

d.  Video  Packet  Data.  A  Format  0  packet  shall  contain  an  integral  number  of  188-byte 
(1504  bits)  TS  packets  as  illustrated  in  Figure  11-48  and  Figure  11-49  depending  on  the 
byte  alignment  bit.  The  IPHs  can  be  inserted  in  Format  0  video  data  packets.  The 
10  MHz  RTC  packet  header  time  is  the  time  of  the  first  bit  of  the  first  TS  in  the  packet. 


The  CBR  of  the  encoding  will  be  user- selectable  and  within  the  MPEG- 2  MP@ML  and 
H.264  MP@L3  specification.  Per  ISO/IEC  138 18- 1:2007 20  the  TS  format  will  be  fixed-length 
188-byte  (1504  bits)  frames  containing  an  8-bit  sync  pattern  or  “sync  byte”  (starting  at  bit  0  and 
ending  at  bit  7  of  the  TS  format).  The  sync  bytes  value  is  010001 1 1  (0x47).  The  rest  of  the  TS 
187  data  bytes  will  follow  (Table  11-35). 


Table  11-35.  Format  0  MPEG-2/H.264  Video  Data  Packet 

(Example  is  16-Bit  Aligned) 

msb  lsb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp 

TS  Sync  Byte  Data  (Bits  15  to  0) 

TS  Data  (Bits  31  to  16) 

TS  Data  (Bits  1487  to  1472) 

TS  Data  (Bits  1503  to  1488) 

(Optional)  Intra-Packet  Time  Stamp 

TS  Sync  Byte  Data  (Bits  15  to  0) 

TS  Data  (Bits  31  to  16) 

TS  Data  (Bits  1487  to  1472) 

TS  Data  (Bits  1503  to  1488) 

20  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology  —  Generic  coding  of  moving  pictures  and  associated  audio  information:  Systems.  ISO/IEC  13818- 
1:2007.  October  2007.  Updated  by  ISO/IEC  13818-1:2013.  Retrieved  26  April  2017.  Available  for  purchase  at 
https://www.iso.org/standard/62074.html. 
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_ (Optional)  Intra-Packet  Time  Stamp 

Repeat  for  each  TS. 


Packet  Trailer 


11.2.10.2  Video  Packets,  Format  1  (ISO  13818-1  MPEG-2  Bit  Stream) 

Unlike  Video  Packets,  Format  0  (MPEG-2)  the  Format  1  packets  encapsulate  the 
complete  ISO/IEC  13818-1:2007  bit  streams  for  both  program  and  transport  with  constant  or 
variable  bit  rates.  Also  any  of  the  profiles  and  level  combinations  as  set  forth  by  ISO/IEC 
13818-1:2007  may  be  utilized  in  the  encoding  process.  The  TSs  are  limited  to  a  single  PS  using 
PES  packets  that  share  the  same  common  time  base.  A  TS  must  contain  the  PAT  and  PMT  that 
define  the  PID  for  the  PCR  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

a.  MPEG-2  Stream  Packet  Body.  The  Format  1  packet  within  MPEG-2  packets  has  the 
basic  structure  shown  in  Table  11-36.  Note  that  the  width  of  the  structure  is  not  related  to 
any  number  of  bits.  This  drawing  is  merely  intended  to  represent  relative  placement  of 
data  in  the  packet. 

Table  11-36.  General  MPEG-2  Video  Packet,  Format  1 

Packet  Header 
Channel-Specific  Data 
(Optional)  Intra-Packet  Header 
MPEG-2  Packet  1 
(Optional)  Intra-Packet  Header 
MPEG-2  Packet  2 


(Optional)  Intra-Packet  Header 
MPEG- 2  Packet  n 
Packet  Trailer 


b.  Video  Packet  Audio.  When  recording  video  using  Format  1,  if  audio  is  present,  it  will  be 
inserted  into  the  TS  per  ISO/IEC  13818-3.  A  separate  analog  channel  to  specifically 
record  audio  will  not  be  required  as  MPEG-2  supports  audio  insertion  into  the  TS  or  PS. 
By  combining  video  and  audio,  recording  bandwidth  and  memory  capacity  will  be 
increased. 


c.  MPEG-2  Channel- Specific  Data  Word.  The  packet  body  portion  of  each  MPEG-2  bit 
stream  begins  with  a  CSDW  formatted  as  shown  in  Figure  11-51. 
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Figure  11-51.  MPEG-2  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-22  are  reserved  for  future  use. 

•  KLV.  Bit  21  indicates  if  KLV  metadata  is  present  in  the  MPEG-2  video  data. 
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0  =  No  KLV  metadata  present 
1  =  KLV  metadata  is  present. 

MPEG-2  stream  KLV  metadata  (if  utilized)  will  be  IAW  MISP  Standard  9711, 
Standard  9712,  Standard  9713,  Recommended  Practice  9717,  and  Standard  0107.1. 

•  SCR/RTC  Sync  (SRS).  Bit  20  indicates  whether  the  MPEG-2  SCR  is  RTC. 

0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC. 

1  =  SCR  is  synchronized  with  the  10  MHz  RTC. 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  SCR.  Within  a  TS,  each  embedded  program  contains  its 
own  PCR,  requiring  that  each  Format  1  encoded  MPEG-2  TS  contain  only  a  single 
program  allowing  each  format  to  be  treated  in  a  similar  manner  using  a  single  global 
clocking  reference. 

The  10  MHz  RTC  is  used  to  synchronize  and  time  stamp  the  data  acquired  from 
multiple  input  sources.  For  input  sources  that  don’t  define  an  explicit  timing  model 
for  data  presentation,  superimposing  this  timing  model  can  be  accomplished.  For 
MPEG-2,  however,  an  explicit  synchronization  model  based  on  a  27  MHz  clock  is 
defined  for  the  capture,  compression,  decompression,  and  presentation  of  MPEG-2 
data.  In  order  to  relate  the  two  different  timing  models,  the  MPEG-2  SCR/PCR  time 
stamps  (if  enabled)  will  be  derived  from  the  10  MHz  RTC  timing  reference  source 
(by  generating  the  27  MHz  MPEG-2  reference  clock  slaved  to  the  10  MHz  RTC). 

MPEG-2  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a  33-bit 
base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  +  SCR_ext 


where: 

SCR_base=  ((system_clock_frequency  *  t)/300)  MOD  233 
SCR_ext=  ((system_clock_frequency  *  t)/l)  MOD  300 

For  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10  MHz  RTC  using  the  equation: 

10  MHz  RTC  time  base  =  SCR  *  10/27  (rounded  to  the  nearest  integer) 

For  recording  periods  longer  than  this,  the  Format  1  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-2  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

•  Intra-Packet  Header  (IPH).  Bit  19  indicates  whether  IPTSs  are  inserted  before  each 
program  or  transport  packet. 

•  Encoding  Profile  and  Level  (EPL).  Bits  18-15  indicate  the  MPEG-2  profile  and  level 
of  the  encoded  bit  stream. 

0000  =  Simple  Profile  @  Main  Level 
0001  =  Main  Profile  @  Low  Level 
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0010  =  Main  Profile  @  Main  Level 
0011  =  Main  Profile  @  High- 1440  Level 
0100  =  Main  Profile  @  High  Level 
0101  =  SNR  Profile  @  Low  Level 
0110  =  SNR  Profile  @  Main  Level 
0111  =  Spatial  Profile  @High-1440  Level 

1000  =  High  Profile  @  Main  Level 

1001  =  High  Profile  @  High- 1440  Level 

1010  =  High  Profile  @  High  Level 

1011  =  4:2:2  Profile  @  Main  Level 

1100  =  Reserved 

1101  =  Reserved 
1110  =  Reserved 
1111=  Reserved 

•  Embedded  Time  (ET).  Bit  14  indicates  whether  embedded  time  is  present  in  the 
MPEG-2  video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 

MPEG-2  stream  embedded  time,  if  utilized,  will  be  IAW  MISP  Standard  9708  and 
Standard  9715.  Embedded  time  is  used  for  the  synchronization  of  core  MPEG-2  data 
when  extracted  from  the  Chapter  10  domain  (i.e.,  an  export  to  MPEG-2  files). 

•  Mode  (MD).  Bit  13  indicates  whether  the  MPEG-2  bit  stream  was  encoded  using  a 
variable  or  CBR  parameter  setting. 

0  =  CBR  stream 
1  =  Variable  bit  rate  stream 

•  Type  (TP).  Bit  12  indicates  the  type  of  data  the  packetized  MPEG-2  bit  stream 
contains. 

0  =  Transport  data  bit  stream 
1  =  Program  data  bit  stream 

•  Packet  Count  (PC).  Bits  11-0  indicate  the  binary  value  of  the  number  of  MPEG-2 
packets  included  in  the  Format  1  packet. 

An  integral  number  of  complete  packets  will  be  in  each  Format  1  packet.  If  the 
MPEG-2  hardware  implementation  is  unable  to  determine  the  value  of  this  number, 
the  value  of  0  is  used  by  default.  If  TYPE  =  0,  then  this  number  represents  the 
number  of  TS  packets  within  the  Format  1  packet.  If  TYPE  =  1,  then  this  number 
represents  the  number  of  PS  packs  within  the  Format  1  packet. 

d.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  MPEG-2  packet  (transport  or  program).  The  length  of  the  IPH  is 
fixed  at  64  bits  (8  bytes)  positioned  contiguously,  in  the  following  sequence  (Figure 
11-52). 
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Time  (LSLW) 

Time  (MSLW) 

Figure  11-52.  Video  Packet,  Format  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual 
MPEG-2  packets  (transport  or  program).  First  long  word  (LSLW)  bits  31-0  and 
second  long  word  (MSLW)  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  MPEG-2  packet 
(transport  or  program).  Bits  31  to  16  in  the  second  long  word  (MSLW)  will 
be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  Time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of 
the  MPEG- 2  packet  (transport  or  program). 

1 1.2. 10.3  Video  Packets,  Lormat  2  (ISO  14496  MPEG-4  Part  10  AVC/H.264) 

Pormat  2  video  encoding  will  be  IAW  ISO  14496  Part  10. 21  The  carrier  format  for 
Lormat  2  AVC/H.264  will  be  ISO/IEC  13818-1:2007  bit  streams  for  both  program  and  transport 
with  constant  or  variable  bit  rates.  AVC/H.264  can  be  carried  over  the  MPEG-2  streams  IAW 
ITU-T  Rec.  H. 222.0. 

Unlike  Pormat  0  video  packets  (MPEG-2/H.264),  which  only  support  a  fixed  MPEG-2 
transport  and  fixed  MPEG-2/H.264  profiles  and  levels,  the  Format  2  AVC/H.264  packets 
encapsulate  the  complete  MPEG-2  TSs/PSs,  provide  for  a  fixed/variable  bit  rate  (Format  1),  and 
include  all  H.264  video  encoding  profiles  and  levels. 

Format  2  AVC/H.264  streams  are  limited  to  a  single  program  or  TS  using  PES  packets 
that  share  the  same  common  time  base.  The  TS  or  PS  must  contain  the  PAT  and  PMT  that 
define  the  PID  for  the  PCR  stream.  The  PSs  also  must  contain  at  least  one  packet  header. 

a.  AVC/H.264  Stream  Packet  Body.  The  Format  2  packet  within  AVC/H.264  packets  has 
the  basic  structure  shown  in  Table  11-37.  Note  that  the  width  of  the  structure  is  not 
related  to  any  number  of  bits.  This  drawing  is  merely  intended  to  represent  relative 
placement  of  data  in  the  packet. 

Table  11-37.  General  AVC/H.264  Video  Packet,  Format  2 

Packet  Header 
Channel-Specific  Data 
(Optional)  Intra-Packet  Header 
AVC/H.264  Packet  1 


lsb 

0 


21  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  -  Coding  of  Audio-Visual  Objects  -  Part  10:  Advanced  Video  Coding.  ISO/IEC  14496-10:2012.  April 
2012.  May  be  superseded  by  update.  Retrieved  26  April  2017.  Available  at 
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html. 
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(Optional)  Intra-Packet  Header 


AVC/H.264  Packet  2 


(Optional)  Intra-Packet  Header 


AVC/H.264  Packet  n 


Packet  Trailer 


b.  Video  Packet  Audio.  When  recording  video  using  Format  2  AVC/H.264,  if  audio  is 
present  it  will  be  inserted  into  the  TS  per  ISO/IEC  13818-3  or  13818-7. 22  A  separate 
analog  channel  to  specifically  record  audio  will  not  be  required  as  AVC/H.264  supports 
audio  insertion  into  the  AVC/H.264  TS.  By  combining  video  and  audio,  recording 
bandwidth  and  memory  capacity  will  be  increased. 

c.  AVC/H.264  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  AVC/H.264 
packet  begins  with  a  CSDW  formatted  as  shown  in  Figure  11-53. 
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Figure  1 1-53.  AVC/H.264  Channel- Specific  Data  Word 


•  Reserved  (R).  Bits  31-27  are  reserved  for  future  use. 

•  AVC/H.264  Audio  Encoding  Type  (AET).  Bit  26  indicates  the  AVC/H.264  audio 
encoding  type. 

0  =  ISO/IEC  13818-3 
1  =  ISO/IEC  13818-7 

•  AVC/H.264  Encoding  Level  (EL).  Bits  25-22  indicate  the  AVC/H.264  level  of  the 
encoded  video  bit  stream. 


0000  =  1 

0001  = 

lb 

0010=  1.1 

0011  = 

1.2 

0100=  1.3 

0101  =  2 

0110  = 

2.1 

0111  =  2.2 

1000  = 

3 

1001  =  3.1 

1010  =  3.2 

1011  = 

4 

1100  =  4.1 

1101  = 

4.2 

1110  =  5 

1111  =  5.1 

•  KLV.  Bit  21  indicates  if  KLV  metadata  is  present  in  the  MPEG-2  video  data. 

0  =  No  KLV  metadata  present 
1  =  KLV  metadata  is  present 

MPEG-2  stream  KLV  metadata  (if  utilized)  will  be  IAW  MISP  Standard  9711, 
Standard  9712,  Standard  9713,  Recommended  Practice  9717,  and  Standard  0107.1. 

•  SCR/RTC  Sync  (SRS).  Bit  20  indicates  whether  the  AVC/H.264  MPEG-2  SCR  is 
RTC. 


22  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology  —  Generic  coding  of  moving  pictures  and  associated  audio  information  --  Part  7:  Advanced  Audio 
Coding  (AAC).  ISO/IEC  13818-7:2006(E).  Geneva:  International  Organization  for  Standardization,  2006. 
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0  =  SCR  is  not  synchronized  with  the  10  MHz  RTC. 

1  =  SCR  is  synchronized  with  the  10  MHz  RTC. 

The  TSs  contain  their  own  embedded  time  base  used  to  facilitate  the  decoding  and 
presentation  of  video  and/or  audio  data  at  the  decoder.  Within  a  PS,  all  streams  are 
synchronized  to  a  single  SCR.  Within  a  TS,  each  embedded  program  contains  its 
own  PCR,  requiring  that  each  Format  0-encoded  MPEG-2  TS  contain  only  a  single 
program  allowing  each  format  to  be  treated  in  a  similar  manner  using  a  single  global 
clocking  reference. 

The  10-MHz  RTC  is  provided  to  synchronize  and  time  stamp  the  data  acquired  from 
multiple  input  sources.  For  input  sources  that  don’t  define  an  explicit  timing  model 
for  data  presentation,  superimposing  this  timing  model  can  be  accomplished.  For 
MPEG-2,  however,  an  explicit  synchronization  model  based  on  a  27  MHz  clock  is 
defined  for  the  capture,  compression,  decompression,  and  presentation  of  MPEG-2 
data.  In  order  to  relate  the  two  different  timing  models,  the  MPEG-2  SCR/PCR  time 
stamps  (if  enabled)  will  be  derived  from  the  10  MHz  RTC  timing  reference  source 
(by  generating  the  27  MHz  MPEG-2  reference  clock  slaved  to  the  10  MHz  RTC). 

MPEG-2  defines  the  SCR/PCR  time  stamp  as  a  42-bit  quantity,  consisting  of  a  33-bit 
base  value  and  a  9-bit  extension  value.  The  exact  value  is  defined  as: 

SCR  =  SCR_base  *  300  +  SCR_ext 

where: 


SCR_base=  [(system_clock_frequency  *  t)/300]  MOD  233 

SCR_ext  =  [(system_clock_frequency  *  t)/l]  MOD  300 

For  recording  periods  of  less  than  26.5  hours,  the  SCR  can  be  directly  converted  into 
the  10  MHz  RTC  using  this  equation: 

10  MHz  RTC  time  base  =  SCR  *  10/27  (rounded  to  nearest  integer). 

For  recording  periods  longer  than  this,  the  Format  0  packet  header  time  stamp  can  be 
used  to  determine  the  number  of  times  the  MPEG-2  SCR  has  rolled  over  and 
calculate  the  upper  8  bits  of  the  free-running  counter’s  value. 

Intra-Packet  Header  (IPH).  Bit  19  indicates  whether  IPTSs  are  inserted  before  each 
program  or  transport  packet. 

AVC/H.264  Encoding  Profile  (EP).  Bits  18-15  indicate  the  AVC/H.264  profile  of  the 
encoded  video  bit  stream. 

0000  =  Baseline  Profile  (BP)  0001  =  Main  Profile  (MP) 

0010  =  Extended  Profile  (EP)  0011  =  High  Profile  (HiP) 

0100  =  High  10  Profile  (HilOP)  0101  =  High  4:2:2  Profile  (Hi422P) 

01 10  =  High  4:4:4  Profile  (Hi444P)  0111-1111  =  Reserved 

Embedded  Time  (ET).  Bit  14  indicates  whether  embedded  time  is  present  in  the 
AVC/H.264  MPEG-2  video  data. 

0  =  No  embedded  time  present 
1  =  Embedded  time  is  present 
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AVC/H.264  MPEG-2  stream  embedded  time  (if  utilized)  will  be  IAW  MISP  Standard 
9708  and  Standard  9715.  Embedded  time  is  used  for  the  synchronization  of  core 
AVC/H.264  data  when  extracted  from  the  Chapter  10  domain,  i.e.,  an  export  to 
AVC/H.264  files. 

•  Mode  (MD).  Bit  13  indicates  whether  the  AVC/H.264  MPEG-2  bit  stream  was 
encoded  using  a  variable  or  CBR  parameter  setting. 

0  =  CBR  stream 

1  =  Variable  bit  rate  stream 

•  Type  (TP).  Bit  12  indicates  the  type  of  data  the  packetized  AVC/H.264  MPEG-2  bit 
stream  contains. 

0  =  Transport  data  bit  stream 

1  =  Program  data  bit  stream 

•  Packet  Count  (PC).  Bits  1 1-0  indicate  the  binary  value  of  the  number  of  AVC/H.264 
packets  included  in  the  Format  2  packet. 

An  integral  number  of  complete  packets  will  be  in  each  Format  2  packet.  If  the 
AVC/H.264  hardware  implementation  is  unable  to  determine  the  value  of  this 
number,  the  value  of  0  is  used  by  default.  If  TYPE  =  0,  then  this  number  represents 
the  number  of  TS  packets  within  the  Format  2  packet.  If  TYPE  =  1,  then  this  number 
represents  of  the  number  of  PS  packets  within  the  Format  2  packet. 

d.  Intra-Packet  Header.  If  enabled,  the  IPH  shall  include  a  64-bit  IPTS,  which  is  inserted 
immediately  before  the  AVC/H.264  packet  (transport  or  program).  The  length  of  the  IPH 
is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  in  the  following  sequence  (Figure 
11-54). 

msb 

31 _ 

Time  (LSLW) 

Time  (MSLW) 

Figure  1 1-54.  Video  Packet,  Format  2  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  individual 
AVC/H.264  packets  (transport  or  program).  First  long  word  (FSFW)  bits  31-0  and 
second  long  word  (MSFW)  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  will  correspond  to  the  first  bit  of  the  AVC/H.264  packet. 
Bits  31  to  16  in  the  second  long  word  (MSFW)  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  bit  of 
the  AVC/H.264  packet. 
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1 1.2. 10.4  Video  Packets,  Format  3  (MJPEG) 

Format  3  video  encoding  will  be  IAW  ISO/IEC  10918  Part  l23used  by  Audio  Video 
Interleaved,  Motion  JPEG  Video.  A  set  of  images  for  this  type  with  compatible  parameters  can 
be  placed  into  an  MJPEG  video  packet  as  shown  in  Table  11-38.  Frame  headers  shall  be  limited 
to  those  specified  in  ISO/IEC  10918  Part  1.  These  types  are  SOFO,  SOF1,  SOF2,  SOF3,  SOF9, 
SOF10,  and  SOF11.  Of  these  types  accommodated,  this  specification  provides  implementation 
only  for  baseline  sequential  discrete  cosine  transform. 


Table  11-38.  MJPEG  Video  Packet,  Format  3 


msb  lsb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  15-0) _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  15-0) 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  47-32) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  63-48) _ 

INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FILLER  (IF  n  IS  ODD) 

FRAME  BYTE  n 

INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FILLER  (IF  n  IS  ODD) 

FRAME  BYTE  n 

PACKET  TRAILER 


An  MJPEG  video  packet  shall  contain  one  or  more  fixed-length  segments  of  a  partial 
MJPEG  frame,  one  complete  MJPEG  frame,  or  multiple  complete  MJPEG  frames. 


MJPEG  video  packet  information  will  be  specified  in  the  CSDW. 


23  International  Organization  for  Standardization/International  Electrotechnical  Commission.  “General  sequential 
and  progressive  syntax”.  Annex  B,  section  B.2,  in  Information  technology  --  Digital  compression  and  coding  of 
continuous-tone  still  images:  Requirements  and  guidelines.  ISO/IEC  10918-1:1994.  May  be  superseded  by  update. 
Geneva:  International  Organization  for  Standardization,  1994. 
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a.  MJPEG  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
MJPEG  video  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body  contains 
several  complete  images  or  partial  images  (Figure  11-55). 
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RESERVED 

Figure  1 1-55.  MJPEG  Video  packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  frames  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  frames. 

00  =  Packet  does  not  contain  first  or  last  segment  of  frame 
01  =  Packet  contains  first  segment  of  frame 
10  =  Packet  contains  last  segment  of  frame 
11=  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  frame  that  spans  multiple 
packets,  one  complete  frame,  or  multiple  complete  frames. 

00  =  Packet  contains  less  than  one  complete  frame  (a  segment) 

01  =  Packet  contains  one  complete  frame 
10  =  Packet  contains  multiple  complete  frames 
11=  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  frame  within  a  packet  or  the  first  segment  of  a  multi- segment 
frame.  An  IPH  (time  stamp)  is  not  required  for  a  frame  segment  if  it  is  not  the  first 
segment  of  a  frame. 

0  =  Intra-Packet  Header  not  enabled 

1  =  Intra-Packet  Header  enabled 

•  Reserved.  Bits  26-0  are  reserved. 

b.  MJPEG  Video  Intra-Packet  Header.  After  the  CSDW,  the  format  3  MJPEG  video  data 
(complete  frame,  multiple  complete  frames,  or  frame  segment)  is  inserted  into  the  packet. 
The  frame  shall  be  preceded  by  an  IPH,  which  shall  provide  the  complete  frame  or  first 
frame  segment  time  stamp  and  the  frame  length.  The  IPH  time  stamp  value  indicates  the 
time  of  the  complete  frame  capture. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-56). 
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JH _ 0_ 

TIME  (LSLW) _ 

TIME  (MSLW) _ 

FRAME  LENGTH _ 

Figure  1 1-56.  MJPEG  Video  Intra-Packet  Header 
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•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Format  3 
MJPEG  video  data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate 
the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  MJPEG  frame  with 
bits  31  to  16  in  the  second  long  word  zero  filled  or; 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  MJPEG  frame. 

•  Intra-Packet  Data  (FRAME  LENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  the  following  complete  frame. 


1 1.2. 10.5  Video  Packets,  Format  4  (MJPEG-2000). 

Format  4  video  encoding  will  be  IAW  ISO/IEC  15444-3:2007  Motion  JPEG  2000. 24  A 
set  of  images  for  this  type  with  compatible  parameters  can  be  placed  into  an  MJPEG-2000  video 
packet  as  shown  in  Table  11-39. 


Table  11-39.  MJPEG  Video  Packet,  Format  4 


msb  lsb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  15-0) _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  15-0) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  31-16) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  47-32) _ 

_ INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  63-48) _ 

INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FILLER  (IF  n  IS  ODD) 

FRAME  BYTE  n 

INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  SEGMENT  1  (BITS  79-64) 
INTRA-PACKET  HEADER  FOR  SEGMENT  n  (BITS  95-80) 


FRAME  BYTE  2 


FRAME  BYTE  1 


24  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
technology:  JPEG  2000  image  coding  system:  motion  JPEG  2000.  ISO/IEC  15444-3:2007.  Geneva:  International 
Organization  for  Standardization,  2007. 
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: 

: 

FILLER  (IF  77  IS  ODD) 

FRAME  BYTE  n 

PACKET  TRAILER 

An  MJPEG-2000  video  packet  shall  contain  one  or  more  fixed-length  segments  of  a 
partial  MJPEG-2000  frame,  one  complete  MJPEG-2000  frame,  or  multiple  complete 
MJPEG-2000  frames. 

MJPEG-2000  video  packet  information  will  be  specified  in  the  CSDW. 


a.  MJPEG-2000  Video  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of 
each  MJPEG-2000  video  packet  begins  with  a  CSDW.  It  indicates  if  the  packet  body 
contains  several  complete  images  or  partial  images  (Figure  11-57). 
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Figure  11-57.  MJPEG  2000  Video  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  frames  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  frames. 

00  =  Packet  does  not  contain  first  or  last  segment  of  frame 
01  =  Packet  contains  first  segment  of  frame 

10  =  Packet  contains  last  segment  of  frame 

11  =  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  frame  that  spans  multiple 
packets,  one  complete  frame,  or  multiple  complete  frames. 

00  =  Packet  contains  less  than  one  complete  frame  (a  segment) 

01  =  Packet  contains  one  complete  frame 
10  =  Packet  contains  multiple  complete  frame 
11=  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  frame  within  a  packet  or  the  first  segment  of  a  multi-segment 
frame.  An  IPH  (time  stamp)  is  not  required  for  a  frame  segment  if  it  is  not  the  first 
segment  of  a  frame. 

0  =  Intra-Packet  Header  not  enabled 

1  =  Intra-Packet  Header  enabled 

•  Reserved.  Bits  26-0  are  reserved. 

b.  MJPEG  Video  Intra-Packet  Header.  After  the  CSDW,  the  format  4  MJPEG-2000  video 
data  (complete  frame,  multiple  complete  frames,  or  frame  segment)  is  inserted  into  the 
packet.  The  frame  shall  be  preceded  by  an  IPH,  which  shall  provide  the  complete  frame 
or  first  frame  segment  time  stamp  and  the  frame  length.  The  IPH  time  stamp  value 
indicates  the  time  of  the  complete  frame  capture. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-58). 
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JH _ 

TIME  (LSLW) 

TIME  (MSLW) 

FRAME  LENGTH 

Figure  11-58.  MJPEG  Video  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Format  4 
MJPEG-2000  video  data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0 
indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  MJPEG-2000 
frame  with  bits  31  to  16  in  the  second  long  word  zero  filled  or; 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  MJPEG-2000  frame. 

•  Intra-Packet  Data  (FRAME  LENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  the  following  complete  frame. 

11.2.11  Image  Packets 

11.2.11.1  Image  Packets,  Format  0  (Image  Data) 

A  Format  0  image  packet  (Table  11-40)  shall  contain  one  or  more  fixed-length  segments 
of  one  or  more  video  images.  The  CSDW  for  an  image  packet  identifies  the  number  of  segments 
in  the  packet  and  the  portion  of  the  image  or  images  contained  in  the  packet.  If  the  optional  IPH 
is  not  included  with  each  segment,  the  RTC  in  the  packet  header  is  the  time  of  the  first  segment 
in  the  packet. 


Table  11-40.  Image  Packet,  Format  0 

msb 

lsb 

15 

0 

Packet  Header 

Channel- Specific  Data  (Bits  15-0) 

Channel- Specific  Data  (Bits  31-16) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Optional  Intra-Packet  Header  for  Segment  1  (Bits  63-48) 

Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  15-0) 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  31-16) 
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Optional  Intra-Packet  Header  for  Segment  N  (Bits  47-32) 

Optional  Intra-Packet  Header  for  Segment  N  (Bits  63-48) 

Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Image  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  image 
packet  begins  with  a  CSDW.  It  defines  the  byte  length  of  each  segment  and  indicates  if 
the  packet  body  contains  several  complete  images  or  partial  images,  and  whether  or  not 
the  IPDH  precedes  each  segment  (Figure  11-59). 
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Figure  11-59.  Image  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  piece  or  pieces  of  the  video  frame  are  contained  in 
the  packet. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 

01  =  Packet  contains  first  segment  of  image 

10  =  Packet  contains  last  segment  of  image 

11=  Packet  contains  both  first  and  last  segment  of  image 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image,  one  complete  image, 
multiple  complete  images,  or  pieces  from  multiple  images. 

00  =  Packet  contains  less  than  one  complete  image 
01  =  Packet  contains  one  complete  image 
10  =  Packet  contains  multiple  complete  images 
11=  Packet  contains  multiple  incomplete  images 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  whether  the  IPH  (time  stamp)  precedes 
each  segment  of  the  image. 

0  =  The  IPH  not  enabled 
1  =  The  IPH  enabled 

•  Length.  Bits  26-0  indicate  a  binary  value  that  represents  the  byte  length  of  each 
segment. 

b.  Image  Intra-Packet  Header.  After  the  channel-specific  data,  Format  0  image  data  is 

inserted  into  the  packet.  Each  block  of  data  is  optionally  preceded  by  an  IPH  as  indicated 
by  the  IPH  bit  in  the  CSDW.  When  included,  the  IPH  consists  of  an  IPTS  only.  The 
length  of  the  IPH  is  fixed  at  8  bytes  (64  bits)  positioned  contiguously,  in  the  following 
sequence  (Figure  11-60). 
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Time  (MSLW) _ 

Figure  1 1-60.  Image  Data  Intra-Packet  Header,  Format  0 


msb 

31 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Format  0  image 
data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  first  byte  with  bits 
31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  image  or  segment. 


1 1.2. 1 1.2  Image  Packets,  Format  1  (Still  Imagery) 

A  Format  1  image  packet  (Table  11-41)  shall  contain  one  or  more  fixed-length  segments 
of  a  partial  still  image,  one  complete  still  image,  or  multiple  still  images.  The  still  image  source 
can  be  external  or  internal  to  the  recorder.  The  still  image  formats  will  be  specified  in  the 
CSDW  and  in  the  Computer- Generated  Data,  Format  1  setup  record  for  each  still  imagery 
channel.  Only  one  format  can  be  contained  within  each  channel  ID  for  still  imagery. 


Table  11-41.  Still  Imagery  Packet,  Format  1 
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_0 

Packet  Header 

_ Channel- Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Intra-Packet  Header  for  Segment  1  (Bits  63-48) 

Intra-Packet  Header  for  Segment  1  (Bits  79-64) 

Intra-Packet  Header  for  Segment  1  (Bits  95-80) 

Byte  2  Byte  1 


Filler  (if  N  is  Odd)  Byte  N 


Intra-Packet  Header  for  Segment  N  (Bits  15-0) 
Intra-Packet  Header  for  Segment  N  (Bits  31-16) 
Intra-Packet  Header  for  Segment  N  (Bits  47-32) 
Intra-Packet  Header  for  Segment  N  (Bits  63-48) 
Intra-Packet  Header  for  Segment  1  (Bits  79-64) 
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15 
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Intra-Packet  Header  for  Segment  N  (Bits  95-80) 

Byte  2 

Byte  1 

Filler  (if  N  is  Odd) 

Byte  N 

Packet  Trailer 

a.  Still  Imagery  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  still 
image  packet  begins  with  a  CSDW.  It  defines  the  format  of  the  still  imagery  format 
(which  will  coincide  with  the  still  imagery  format  with  the  setup  record),  and  indicates  if 
the  packet  body  contains  several  complete  images  or  partial  images  (Figure  11-61). 
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Figure  11-61.  Still  Imagery  Packet  Channel- Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  piece  or  pieces  of  the  image  are  contained  in  the 
packet. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 
01  =  Packet  contains  first  segment  of  image 

10  =  Packet  contains  last  segment  of  image 

11  =  Packet  contains  both  first  and  last  segment  of  image 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image,  one  complete  image, 
multiple  complete  images,  or  pieces  from  multiple  images. 

00  =  Packet  contains  less  than  one  complete  image 
01  =  Packet  contains  one  complete  image 
10  =  Packet  contains  multiple  complete  images 
11=  Packet  contains  multiple  incomplete  images 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  whether  the  IPH  (time  stamp)  precedes 
each  segment  of  the  image. 

0=  The  IPH  not  enabled 
1=  The  IPH  enabled 

•  Format.  Bits  26-23  indicate  a  binary  value  that  represents  the  still  image  format. 

0000  =  MIL-STD-250025  National  Imagery  Transmission  Format 
0001  =  JPEG  File  Interchange  Format 
0010  =  JPEG  2000  (ISO/IEC  15444-1)26 


25  Department  of  Defense.  “National  Imagery  Transmission  Format  Version  2.1.”  MIL-STD-2500C.  May  2006. 
May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  at 
http://Quicksearch.dla.mil/qsDocDetails.aspx7ident  number=l  12606. 

26  International  Organization  for  Standardization/International  Electrotechnical  Commission.  Information 
Technology  —  JPEG  2000  Image  Coding  System:  Core  Coding  System.  ISO/IEC  15444-1:2016.  October  2016. 
May  be  superseded  by  update.  Retrieved  27  April  2017.  Available  for  purchase  at 
http://www.iso.org/iso/home/store/catalogue  tc/catalogue  detail. htm?csnumber=37674. 
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0011  =  Portable  Network  Graphics  Format 
0100-1111=  Reserved 

•  Reserved.  Bits  22-0  are  reserved. 

b.  Still  Imagery  Intra-Packet  Header.  After  the  channel- specific  data,  Format  1  still  imagery 
data  is  inserted  into  the  packet.  Each  still  image  or  segment  is  preceded  by  an  IPH.  The 
IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12  bytes 
(96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-62). 


Figure  1 1-62.  Still  Imagery  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Format  1  still 
imagery  data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the 
following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  still  image  or 
segment  with  bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  still  image  or  segment. 

•  Intra-Packet  Data.  These  4  bytes  indicate  a  binary  value  that  represents  the  byte 
length  of  the  following  still  image  or  segment. 


11.2.11.3  Image  Packets,  Format  2  (Dynamic  Imagery). 

A  Format  2  image  packet  (Table  11-42)  shall  contain  one  or  more  fixed-length  segments 
of  a  partial  dynamic  image,  one  complete  dynamic  image,  or  multiple  complete  dynamic  images. 
Typically  dynamic  image  packets  will  be  created  from  cameras  attached  to  a  recorder  or  cameras 
that  include  a  recording  capability. 

Table  11-42.  Dynamic  Imagery  Packet,  Format  1 

msb  lsb 

_L5 _ 0_ 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) _ 

Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Header  for  Segment  1  (Bits  15-0) 

Intra-Packet  Header  for  Segment  1  (Bits  31-16) 

Intra-Packet  Header  for  Segment  1  (Bits  47-32) 

Intra-Packet  Header  for  Segment  1  (Bits  63-48) 
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Intra-Packet  Header  for  Segment  1  (Bits  79-64) 


Intra-Packet  Header  for  Segment  1  (Bits  95-80) 


Image  Byte  2 

Image  Byte  1 

Filler  (if  n  is  Odd) 

Image  Byte  N 

Intra-Packet  Header  for  Segment  N  (Bits  15-0) 
Intra-Packet  Header  for  Segment  N  (Bits  31-16) 
Intra-Packet  Header  for  Segment  N  (Bits  47-32) 
Intra-Packet  Header  for  Segment  N  (Bits  63-48) 
Intra-Packet  Header  for  Segment  1  (Bits  79-64) 


Intra-Packet  Header  for  Segment  N  (Bits  95-80) 


Image  Byte  2 

Image  Byte  1 

Filler  (if  n  is  Odd) 

Image  Byte  N 

Packet  Trailer 

Each  source  of  dynamic  imagery  (camera  or  sensor)  shall  have  its  own  individual  channel 
ID  value.  Multiple  sources  of  dynamic  imagery  (camera  or  sensor)  shall  not  share  the  same 
channel  ID  value.  Dynamic  Imagery,  Format  2  is  defined  as  image  data  that  has  a  rate  as 
opposed  to  Format  1  still  imagery,  which  does  not. 

Dynamic  image  information  will  be  specified  in  the  CSDW  and  in  the  Computer- 
Generated  Data,  Format  1  setup  record  for  each  dynamic  imagery  channel.  Only  one  dynamic 
imagery  format  can  be  defined  for  each  Format  2  image  packet  channel  ID. 

If  changes  are  made  to  the  initial  dynamic  imagery  channel  settings  in  the  Computer- 
Generated  Data,  Format  1  setup  record  a  new  setup  record  packet  shall  be  created  prior  to  any 
Format  2  image  packets  to  which  the  new  settings  are  applied.  These  changes  shall  be  noted  as  a 
setup  record  configuration  change  in  the  Computer-Generated  Data,  Format  1  setup  record 
CSDW. 

a.  Dynamic  Imagery  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
dynamic  image  packet  begins  with  a  CSDW.  It  defines  the  format  of  the  dynamic 
imagery  format  (which  will  coincide  with  the  dynamic  imagery  format  with  the  setup 
record)  and  indicates  if  the  packet  body  contains  several  complete  images  or  partial 
images  (Figure  11-63). 
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Figure  11-63.  Dynamic  Imagery  Packet  Channel-Specific  Data  Word 


•  Parts.  Bits  31-30  indicate  which  segment  of  the  image  is  contained  in  the  packet  if 
the  packet  does  not  contain  one  or  more  complete  images. 

00  =  Packet  does  not  contain  first  or  last  segment  of  image 
01  =  Packet  contains  first  segment  of  image 
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10  =  Packet  contains  last  segment  of  image 

11  =  Reserved 

•  Sum.  Bits  29-28  indicate  if  the  packet  contains  a  partial  image  that  spans  multiple 
packets,  one  complete  image,  or  multiple  complete  images. 

00  =  Packet  contains  less  than  one  complete  image  (a  segment) 

01  =  Packet  contains  one  complete  image 

10  =  Packet  contains  multiple  complete  images 

11  =  Reserved 

•  Intra-Packet  Header  (IPH).  Bit  27  indicates  that  the  IPH  (time  stamp/data)  shall 
precede  each  complete  image  within  a  packet  or  the  first  segment  of  a  multi-segment 
image.  The  time  stamp  applied  to  each  complete  image  or  first  segment  of  an  image 
is  dependent  on  the  time  stamp  mode  as  defined  in  Subsection  1 1.2.1 1.3  item  b.  An 
IPH  (time  stamp)  is  not  required  for  an  image  segment  if  it  is  not  the  first  segment  of 
an  image. 

0=  The  IPH  is  not  enabled 
1=  The  IPH  is  enabled 

•  Format.  Bits  26-21  indicate  a  binary  value  that  represents  the  dynamic  image  pixel 
format  IAW  GenICam  Standard  Features  Naming  Convention  v  1.5  27  or  later  and 
GigE  Vision  v  1.2  28  or  later. 

0x00  =  Mono  8 
0x01  =  Mono8Signed 
0x02  =  Mono  10 
0x03  =  MonolOPacked 
0x04  =  Mono  12 
0x05  =  Monol2Packed 
0x06  =  Mono  14 
0x07  =  Mono  16 
0x08  =  BayerGR8 
0x09  =  BayerRG8 
0x0  A  =  BayerGB8 
OxOB  =  BayerBG8 
OxOC  =  BayerGRIO 
OxOD  =  BayerRGlO 
OxOE  =  BayerGBlO 
OxOF  =  BayerBGlO 
0x10  =  BayerGR12 
0x1 1  =  BayerRG12 
0x12  =  BayerGB12 


27  European  Machine  Vision  Association.  GenICam  Standard  Features  Naming  Convention.  Version  1.5. 
November  2011.  Retrieved  27  April  2017.  Available  at  http://www.emva.org/wp- 
content/uploads/GenlCam  SFNC  1  5.pdf. 

28  Automated  Imaging  Association.  GiGE  Vision.  Version  1.2.  n.d.  Retrieved  27  April  2017.  Available  for 
download  with  registration  at  http://www.visiononline.org/form.cfm7form  id=735. 
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0x13  =  BayerBG12 
0x14  =  BayerGRIOPacked 
0x15  =  BayerRGlOPacked 
0x16  =  BayerGBlOPacked 
0x17  =  BayerBGlOPacked 
0x18  =  BayerGR12Packed 
0x19  =  BayerRG12Packed 
Oxl  A  =  BayerGB12Packed 
Ox  IB  =  BayerBG12Packed 
OxlC  =  BayerGR16 
OxlD  =  BayerRG16 
OxlE  =  BayerGB16 
OxlF  =  BayerBG16 
0x20  =  RGB8Packed 
0x21  =  BGR8Packed 
0x22  =  RGBA8Packed 
0x23  =  BGRA8Packed 
0x24  =  RGBlOPacked 
0x25  =  BGRIOPacked 
0x26  =  RGB12Packed 
0x27  =  BGR12Packed 
0x28  =  RGB16Packed 
0x29  =  BGR16Packed 
0x2  A  =  RGB  10V1  Packed 
0x2B  =  BGR10V1  Packed 
0x2C  =  RGB  1 0  V  2Packed 
0x2D  =  B  GR 1 0  V  2Packed 
0x2E  =  RGB  12V1  Packed 
0x2F  =  RGB565Packed 
0x30  =  BGR565Packed 
0x31  =  YUV4 11  Packed 
0x32  =  YUV 422Packed 
0x33  =  YUV 444Packed 
0x34  =  YUYVPacked 
0x35  =  RGB8Planar 
0x36  =  RGB  lOPlanar 
0x37  =  RGB  12Planar 
0x38  =  RGB  16Planar 
0x39-0x3E  =  Reserved 
Ox3F  =  Device- specific 

•  Reserved.  Bits  20-0  are  reserved. 

b.  Dynamic  Imagery  Intra-Packet  Header.  After  the  CSDW,  the  Format  2  dynamic  imagery 
data  (complete  image,  multiple  complete  images,  or  image  segment)  is  inserted  into  the 
packet.  The  image  shall  be  preceded  by  an  IPH;  this  IPH  shall  provide  the  complete 
image  or  first  image  segment  time  stamp  and  the  image  length.  The  IPH  time  stamp 
value  indicates  the  time  of  the  complete  image  at  sensor/camera  capture. 
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The  image  time  stamp  characteristics  are  further  defined  within  the  setup  record  dynamic 
imagery  packet  channel  attributes.  Due  to  the  fact  that  dynamic  imagery  may  be  captured 
and  then  packetized  post-capture  there  maybe  uniqueness  in  regards  to  time  stamping  of 
the  data  versus  packet  header/secondary  header  values  related  to  the  first  bit  of  data 
within  the  packet  as  defined  in  sections  11.2.1.1  item  i  and  11.2.1.2  item  a.  Individual 
image  IPH  time  stamp  modes  are  defined  as  follows. 

(1)  Image  Capture  Time.  The  IPH  TIME  value  corresponds  to  the  RTC  or  absolute 
time  when  the  image  was  captured  by  the  sensor/camera.  The  packet  header 
RTC/packet  secondary  header  values  indicate  when  the  first  bit  of  data  is  placed 
into  the  packet.  When  Image  Capture  Time  mode  is  indicated  in  the  setup  record  it 
is  understood  there  is  a  delay  period  between  packet  header  RTC/secondary  header 
time  and  IPH  time. 

(2)  Image  Packetization  Time.  The  IPH  TIME  value  corresponds  to  the  RTC  or 
absolute  time  when  the  image  was  packetized.  The  packet  header  RTC/secondary 
header  values  indicate  when  the  first  bit  of  data  is  placed  into  the  packet.  Image 
packetization  time  is  defined  as  packetizing  image  data  as  it  is  captured  by  the 
sensor/camera.  When  Image  Packetization  Time  mode  is  indicated  in  the  setup 
record  it  is  understood  there  is  not  a  delay  period  between  packet  header 
RTC/secondary  header  time  and  the  image  IPH  time. 

The  IPH  consists  of  an  IPTS  and  intra-packet  data.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-64). 


Figure  11-64.  Dynamic  Imagery  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp  (TIME).  These  8  bytes  indicate  the  time  tag  of  the  Format  2 
dynamic  imagery  data  as  defined  in  Section  11.2.11.3  item  b.  First  long  word  bits  31- 
0  and  second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  dynamic  image 
with  bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  dynamic  image. 

•  Intra-Packet  Data  (IMAGE  FENGTH).  These  4  bytes  indicate  a  binary  value  that 
represents  the  byte  length  of  following  complete  image. 
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11.2.12  UART  Data  Packets 

1 1.2.12.1  UART  Data  Packets,  Format  0 

The  data  from  one  or  more  separate  asynchronous  serial  communication  interface 
channels  (RS-232,  RS-422,  RS-485,  etc.)  can  be  placed  into  a  UART  data  packet  as  shown  in 
Table  11-43.  Note  that  9  bit  UART  data  is  not  supported  by  this  format. 


Table  11-43.  UART  Data  Packet  Format 

msb 

lsb 

15 

0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  1  (Bits  63-48) 

Intra-Packet  Data  Header  (UART  ID)  for  UART  1  (Bits  15-0) 

Intra-Packet  Data  Header  (UARr 

r  ID)  for  UART  1  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  UART  N  (Bits  63-48) 

Intra-Packet  Data  Header  (UART  ID)  for  UART  N  (Bits  15-0) 

Intra-Packet  Data  Header  (UARr 

r  ID)  for  UART  N  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

a.  UART  Packet  Channel- Specific  Data  Word.  The  packet  body  portion  of  each  UART 
data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-65. 
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Figure  1 1-65.  UART  Packet  Channel-Specific  Data  Word 


•  Intra-Packet  Header.  Bit  31  indicates  whether  the  IPH  time  stamp  is  inserted  before 
the  UART  ID  words. 

0  =  The  IPH  time  stamp  not  enabled 
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1  =  The  IPH  time  stamp  enabled 
•  Reserved.  Bits  30-0  are  reserved. 

b.  UART  Intra-Packet  Header.  After  the  channel-specific  data,  UART  data  is  inserted  into 
the  packet.  Each  block  of  data  shall  be  preceded  by  an  IPH  with  optional  IPTS  and  a 
mandatory  UART  ID  word  IPDH.  The  length  of  the  IPH  is  either  4  bytes  (32  bits)  or  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-66). 


Figure  11-66.  UART  Data  Intra-Packet  Header 


•  UART  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  UART 
data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  first  byte  with  bits 
31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  message. 

•  UART  Intra-Packet  Data  Header.  The  IPDH  is  a  UART  ID  word  that  precedes  the 
data  and  is  inserted  into  the  packet  with  the  following  format.  Inclusion  of  the  IPDH 
is  mandatory  and  is  not  controlled  by  the  IPH  bit  in  the  CSDW  (Figure  11-67). 
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Figure  11-67.  Intra-Packet  Data  Header  Format 


o  Parity  Error  (PE).  Bit  31  indicates  a  parity  error. 

0  =  No  parity  error 
1  =  Parity  error 

o  Reserved.  Bit  30  is  reserved. 

o  Subchannel.  Bits  29-16  indicate  a  binary  value  defining  the  subchannel 
number  belonging  to  the  data  that  follows  the  UART  ID  word  when  the 
channel  ID  in  the  packet  header  defines  a  group  of  subchannels.  Zero  means 
first  and/or  only  subchannel  into  which  the  IPDH  is  inserted  before  the  UART 
ID  words. 

o  Data  Fength.  Bits  15-0  indicate  a  binary  value  representing  the  length  of  the 
UART  data  in  bytes  ( n )  that  follows  the  UART  ID  word. 
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11.2.13  IEEE  1394  Data  Packets 

1 1.2.13.1  IEEE  1394  Data  Packets,  Format  0(IEEE  1394  Transaction) 

This  format  applies  to  IEEE  1394  data  as  described  by  IEEE  1394-2008. 29  The  IEEE 
1394  data  is  packetized  to  encapsulate  completed  transactions  between  nodes.  A  packet  may 
contain  0  to  65,536  transactions,  but  is  constrained  by  the  common  packet  element  size  limits 
prescribed  in  Subsection  1 1.2.1.  The  IEEE  1394  packets  have  the  basic  structure  shown  in  Table 
1 1-44.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  The  table  merely 
represents  relative  placement  of  data  within  the  packet. 

Table  11-44.  IEEE  1394  Data  Packet,  Format  0 

Packet  Header _ 

Channel- Specific  Data  Word 

(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 
(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 


(Optional)  Intra-Packet  Header 
(Optional)  Transaction  Data 
Packet  Trailer 


a.  IEEE  1394  Channel-Specific  Data  Word.  The  packet  body  portion  (Figure  11-68)  of 
each  IEEE  1394  packet  shall  begin  with  a  CSDW. 
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Figure  11-68.  IEEE  1394  Channel-Specific  Data  Word 


•  Packet  body  Type  (PBT).  Bits  31-29  indicate  the  packet  body  type  as  follows: 

000  =  Type  0 
001  =  Type  1 
010  =  Type  2 
Oil-  111=  Reserved 

•  Synchronization  Code  (SY).  Bits  28-25  indicate  the  IEEE  1394  synchronization  code 
from  the  transaction.  This  field  is  mandatory  for  Type  1  packet  bodies.  Otherwise,  it 
is  reserved. 

•  Reserved.  Bits  24-16  are  reserved. 

•  Transaction  Count  (TC).  Bits  15-0  indicate  the  binary  value  of  the  number  of 
transactions  encapsulated  in  the  packet.  An  integral  number  of  complete  transactions 


29  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High-Performance  Serial  Bus.  IEEE  1394- 
2008.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  2008. 
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shall  be  included  in  each  packet.  It  is  mandatory  that  transaction  count  be  0  for  Type 
0  packet  bodies  and  1  for  Type  1  packet  bodies. 

b.  IEEE  1394  Intra-Packet  Header.  Each  IPH  shall  contain  an  8-byte  IPTS  only.  The 
format  of  an  IEEE  1394  IPH  is  described  by  Figure  11-69. 

msb 

_31 _ 

Intra-Packet  Time  Stamp 

Intra-Packet  Time  Stamp 

Figure  11-69.  IEEE  1394  Intra-Packet  Header 

•  IEEE  1394  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  IEEE 
1394  transaction  that  immediately  follows  it  in  the  packet.  Time  is  coded  IAW  all 
other  Chapter  1 1  packet  formats.  Specifically,  the  first  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  of  the  transaction,  with 
bits  31-16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  transaction. 

c.  IEEE  1394  Data  Packet  Body  Types.  Three  packet  body  types  are  defined  for  the 
encapsulation  of  IEEE  1394  data.  Regardless  of  type,  each  packet  body  shall  begin  with 
the  IEEE  1394  packet  CSDW  as  described  by  Subsection  11.2.13.1  item  a  above.  The 
packet  body  type  is  indicated  within  the  CSDW.  Depending  on  the  packet  body  type,  the 
CSDW  is  followed  by  0  or  more  transactions.  In  addition,  dependent  on  packet  body 
type,  each  transaction  may  be  preceded  by  an  IPH. 

•  IEEE  1394  Packet  Body  Type  0:  Bus  Status.  Type  0  packet  bodies  shall  contain  zero 
IPHs  and  zero  transactions.  The  CSDW  transaction  count  shall  be  zero.  The  packet 
body  shall  contain  the  CSDW  immediately  followed  by  a  single  32-bit  word. 

Bus  status  events  shall  be  encapsulated  by  Type  0  packet  bodies.  The  32-bit  word  in 
the  packet  body  shall  contain  an  event  data  word  as  indicated  in  Figure  11-70. 
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Figure  1 1-70.  IEEE  1394  Event  Data  Word 


o  RESET  (RE).  Bit  31,  when  set,  indicates  that  an  IEEE  1394  bus  reset  has 
occurred. 

o  RESERVED.  Bits  30-0  are  reserved. 

•  IEEE  1394  Packet  Body  Type  1:  Data  streaming.  Type  1  packet  bodies  shall 

encapsulate  IEEE  1394  data  streaming  only.  Type  1  packet  body  data  is  restricted  to 
that  from  an  IEEE  1394  packet  with  a  transaction  code  of  OxA,  be  it  from  an 
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isochronous  channel  or  asynchronous  stream.  The  packet  body  shall  contain  zero 
IPHs  and  one  transaction.  The  CSDW  transaction  count  shall  be  one. 

The  CSDW  is  immediately  followed  by  a  non-zero  number  of  data  bytes.  The  data 
bytes  shall  be  exactly  those  of  a  single  IEEE  1394  data  block,  excluding  the  IEEE 
1394  packet  header  and  data  block  CRC.  Data  recorded  from  the  stream  shall  be 
known  to  be  valid,  insofar  as  both  the  IEEE  1394  header  CRC  and  data  block  CRC 
tests  have  passed.  The  number  of  data  bytes  shall  be  exactly  four  less  than  the  value 
indicated  in  data  length  IAW  the  definition  of  packet  header  data  length  and 
accounting  for  the  size  of  the  CSDW.  Conversely,  the  value  stored  in  the  packet 
header  data  length  shall  be  the  number  of  bytes  in  the  IEEE  1394  data  block  plus 
four.  The  synchronization  code  (SY)  from  the  stream  packet  shall  be  indicated  in  the 
CSDW,  and  the  channel  number  shall  be  indicated  in  the  packet  header  channel  ID. 

•  IEEE  1394  Packet  Body  Type  2:  General-Purpose.  Type  2  packet  bodies  encapsulate 
complete  IEEE  1394  packets,  including  header  and  data.  Use  of  Type  2  packet 
bodies  is  unrestricted  and  may  encapsulate  streaming,  non-streaming  (IEEE  1394 
packets  with  transaction  codes  other  than  OxA),  isochronous,  and  asynchronous  data. 
Multiple  IEEE  1394  packets,  with  differing  transaction  codes  and  channel  numbers, 
may  be  carried  within  a  single  Type  2  packet  body. 

The  CSDW  shall  be  followed  by  a  non-zero  number  of  completed  transactions  as 
indicated  by  the  CSDW  transaction  count.  Each  transaction  shall  be  preceded  by  an 
IPH  as  defined  above  for  IEEE  1394  data  packets.  Immediately  following  the  IPH, 
the  transaction  shall  be  recorded  in  its  entirety  and  must  be  a  properly  formed  IEEE 
1394  packet  IAW  the  specification  in  use.  The  revision  of  the  specification  used  shall 
be  declared  within  the  accompanying  setup  record  packet. 


All  IEEE  1394  packets  contain  a  4-bit  Transaction 
Code  field  (tcode).  This  field  indicates  the  IEEE 
1394  specific  format  of  the  transaction. 


NOTE 


1 1.2.13.2  IEEE  1394  Data  Packets,  Format  1  (IEEE  1394  Physical  Layer). 

This  format  applies  to  IEEE  1394  data  as  described  by  IEEE  1394-1995,  IEEE  1394a, 
and  IEEE  1394b.  The  IEEE  1394  data  is  packetized  in  Format  1  packets  as  physical  layer  data 
transfers  (IAW  Annex  J  of  Standard  1394- 1995 30  and  Chapter  17  of  Standard  1394b-200231).  A 
packet  may  contain  0  to  65,536  transfers,  but  is  constrained  by  the  common  packet  element  size 
limits  prescribed  in  Subsection  11.2.1.  The  IEEE  1394  packets  have  the  basic  structure  shown  in 
Table  11-45  below.  Note  that  the  width  of  the  structure  is  not  related  to  any  number  of  bits.  The 
drawing  merely  represents  relative  placement  of  data  within  the  packet. 


30  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High  Performance  Serial  Bus.  IEEE  1394- 
1995.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  1995. 

31  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  a  High  Performance  Serial  Bus:  Amendment 
2.  IEEE  1394b-2002.  New  York:  Institute  of  Electrical  and  Electronics  Engineers,  2002. 
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Table  11-45.  IEEE  1394  Data  Packet,  Format  1 

Packet  Header _ 

Channel-Specific  Data  Word _ 

Intra-Packet  Header 

Data _ 

(Optional)  Intra-Packet  Header 
(Optional)  Data 


(Optional)  Intra-Packet  Header 
(Optional)  Data _ 

Packet  Trailer 


a.  IEEE  1394  Channel-Specific  Data  Word.  The  packet  body  portion  (Figure  11-71)  of 
each  IEEE  1394  packet  shall  begin  with  a  CSDW. 
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Figure  11-71.  IEEE  1394  Channel-Specific  Data  Word,  Format  1 


•  Reserved.  Bits  31-16  are  reserved. 

•  Intra-Packet  Count  (IPC).  Bits  15-0  indicate  the  binary  value  of  the  number  of  intra¬ 
packets  encapsulated  in  the  Chapter  1 1  packet.  An  integral  number  of  complete  intra¬ 
packets  shall  be  included  in  each  Chapter  1 1  packet. 

b.  IEEE  1394  Format  1  Intra-Packet  Header.  The  CSDW  is  followed  by  1  or  more  IEEE 
1394  transfers.  Each  transfer  starts  with  an  IPH,  followed  by  0-32,780  encapsulated  data 
bytes.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96  bits)  positioned  contiguously,  in  the 
following  sequence  as  shown  in  Figure  11-72. 
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Intra-Packet  Time  Stamp 
Intra-Packet  Time  Stamp 
Intra-Packet  ID  Word 

Figure  11-72.  IEEE  1394  Format  1  Intra-Packet  Header 

•  IEEE  1394  Format  1  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of 
the  IEEE  1394  transfer  that  immediately  follows  it  in  the  packet.  Time  is  coded  LAW 
all  other  Chapter  1 1  packet  formats.  Specifically,  the  first  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  byte  of  the  transfer,  with  bits 
15-0  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
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(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
byte  of  the  transfer. 


•  Message  ID  Word.  These  4  bytes  are  an  ID  word  that  precedes  the  message  and  is 
inserted  into  the  packet  as  in  Figure  11-73. 
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Figure  11-73.  Intra-Packet  Data  Header  -  Message  ID  Word 


o  Status  Byte.  Bits  31-24  define  the  status  byte  received  from  the  physical  layer 
devices  IAW  IEEE  1394b  specification. 

o  Transmission  Speed  (SPEED).  Bits  23-20  identify  the  speed  of  transmission 
of  the  message.  (Speed  codes  IAW  IEEE  1394b) 

0000  =  S  100  A 

0001  =  S  100  B 

0010  =  S200 A 

0011  =  S200B 

0100  =  S400 A 

0101  =  S400B 

0111  =  S800B 

1001  =  S1600B 

1010  =  S3200  B 

Other  values  are  reserved 

o  Transfer  Overflow  Error  (TRFOVF).  Bits  19-18  indicate  if  a  transfer 
synchronization  error  occurred. 

00  =  IEEE  1394  flow  did  not  exceed  maximum  intra-packet  size. 

01  =  This  IEEE  1394  transfer  started  correctly  but  longer  than  the  standard 
transfer  length. 

10  =  The  previous  IEEE  1394  transfer  was  in  01 -type  overflow  and  this 

IEEE  1394  transfer  ended  correctly  (did  not  exceed  standard  transfer 
length). 

11  =  The  previous  IEEE  1394  transfer  was  in  01-type  overflow  and  this 

IEEE  1394  transfer  did  not  end  correctly  (exceeds  standard  transfer 
length). 

Most  of  the  time,  this  field  shall  be  00.  Possible  combinations  are:  01  intra¬ 
packet,  zero  or  more;  11  intra-packet;  and  finally  10  intra-packet. 

o  Local  Buffer  Overflow  (LBO).  Bit  17,  if  set,  indicates  that  some  messages  are 
lost  before  this  transfer  due  to  local  buffer  overflow. 

o  Reserved  (RSV).  Bit  16  is  reserved. 

o  Data  Length.  Bits  15-0  contain  a  binary  value  that  represents  the  length  of  the 
transfer  in  bytes  (n)  that  follows  the  ID  word.  The  maximum  length  of  a 
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captured  data  is  4120  for  transfers  corresponding  to  asynchronous  packets  and 
32,780  for  transfers  corresponding  to  isochronous  packets. 

If  the  data  length  field  is  not  a  multiple  of  4  bytes,  1-3  fill  bytes  of  0x00  are 
added  to  maintain  the  packet  structures  in  32-bit  boundary. 

If  the  data  length  field  contains  0,  the  intra-packet  data  is  not  provided  and 
this  word  contains  only  the  status  byte  information. 

c.  IEEE  1394  Format  1  Packet  Body.  The  packet  body  shall  encapsulate  IEEE  1394 
isochronous  or  asynchronous  message  data.  The  data  bytes  shall  be  exactly  those  of  a 
single  IEEE  1394  physical  transmission  message,  including  the  IEEE  1394  packet  header 
and  data  block  CRC.  The  data  length  field  shall  indicate  the  exact  number  of  total  bytes 
encapsulated  in  the  message  data. 

11.2.14  Parallel  Data  Packet 

11.2.14.1  Format  0 

Parallel  data  packets  are  designed  to  record  data  from  parallel  interfaces  (2-128  bit  wide) 
including  the  industry  de  facto  standard  8-bit  Digital  Cartridge  Recording  System  -  Incremental 
(DCRsi)  interface.  A  single  packet  can  hold  data  words  or  special  data  structures  as  currently 
defined  for  the  DCRsi  scan  format.  The  exact  format  selection  is  defined  in  the  CSDW.  The 
data  recorded  from  a  parallel  interface  shall  be  placed  into  a  Parallel  Data  Packet,  Format  0  as 
shown  in  Table  11-46. 


a.  Parallel  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  parallel 
data  packet  begins  with  a  CSDW.  The  CSDW  is  formatted  as  shown  in  Figure  11-74. 
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Figure  11-74. 

Parallel  Packet  Channel-Specific  Data  Word 

•  Type.  Bits  31-24  indicate  the  data  type  stored. 

0x01  -  0x00:  Reserved 

0x80  -  0x10:  Number  of  bits  of  recorded  data  (parallel  data  word  width  in  bits) 
OxFD  -  0x8 1 :  Reserved 


11-95 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


OxFE:  DCRsi  scan  format,  contains  auxiliary  data,  DCRsi  main  data 
OxFF:  Reserved 

•  Scan  Number.  Bits  23-0  are  reserved  (0)  for  general-purpose  parallel  data  packets  or 
contain  the  scan  number  of  the  first  scan  stored  in  the  packet  for  DCRsi  data. 

b.  General-Purpose  Parallel  Data.  General-purpose  parallel  data  packets  can  contain  any 
number  of  data  bytes,  as  indicated  in  the  data  length  field  in  the  packet  headers  (Figure 
11-75). 
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Figure  11-75.  Parallel  Data,  Up  to  8-Bit-Wide  Words 


NOTE 


y 


To  get  the  number  of  data  words  stored  in  the  packet, 
the  data  length  must  be  divided  by  the  number  of 
bytes  necessary  to  hold  one  parallel  data  word. 


•  If  the  number  of  data  bits  is  8  or  less,  the  word  shall  be  padded  with  zeros  to  8-bit 
bytes. 

•  If  the  number  of  data  bits  is  between  9  and  16,  the  words  shall  be  padded  with  zeros 
to  one  16-bit  word,  as  in  Figure  11-76. 
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Figure  11-76.  Parallel  Data,  9-Bit  to  16-Bit-Wide  Words 


•  If  the  number  of  data  bits  is  greater  than  16,  the  words  shall  be  padded  with  zeros  to 
multiples  of  16-bit  data  words.  Figure  11-77  shows  storing  of  28-bit  data  words. 


msb 

15 

lsb 

0 

Data  Word  1,  lsbs  15-0 

Pad 
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Data  Word  N,  lsbs  15-0 

Pad 

Data  Word  N,  msbs  27-16 

Figure  1 1-77.  Parallel  Data  (Example:  28-Bit-Wide  Words) 


c.  DCRsi  Parallel  Data  Packets.  The  DCRsi  data  packets  can  contain  any  number  of 
complete  DCRsi  scans,  containing  9  auxiliary  data  and  4356  main  data  bytes.  The 
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number  of  the  scans  can  be  calculated  from  the  data  length  field  of  the  packet  header. 
The  structure  of  one  DCRsi  scan  is  in  Figure  11-78. 
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Figure  11-78.  DCRsi  Scan,  9-Auxiliary  Data  Byte  +  4326  Bytes 


The  length  of  the  packet  can  be  only  N  *  (12  +  4356)  +  4  bytes,  including  the  length  of 
the  CSDW. 

Any  DCRsi  data  without  auxiliary  data  bytes  can  be  stored  also  as  8-bit  general-purpose 
parallel  data  as  described  in  Subsection  11.2.14  item  b. 

11.2.15  Ethernet  Data  Packets 


11.2.15.1  Ethernet  Data  Packets,  Format  0 

Data  from  one  or  more  Ethernet  network  interfaces  can  be  placed  into  an  Ethernet  Data 
Packet  Format  0  as  shown  in  Table  11-47. 


Table  11-47.  Ethernet  Data  Packet,  Format  0 
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15 _ 0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) _ 

Channel-Specific  Data  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 


Intra-Packet  Data  Header 

br  Msg  1  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  n 

Intra-Packet  Time  Stamp  for  Msg  n  (Bits  15-0) 
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Intra-Packet  Time  Stamp  for  Msg  n  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  63-48) 


Intra-Packet  Data  Header  for  Msg  n  (Bits  15-0) 


Intra-Packet  Data  Header 

br  Msg  n  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  n 

Packet  Trailer 

a.  Ethernet  Data  Packet  Format  0,  Channel-Specific  Data  Word.  The  packet  body  portion 
of  each  Ethernet  data  packet  begins  with  a  CSDW.  It  indicates  the  format  of  the  Ethernet 
data  packet  contents,  applicable  TTBs,  and  how  many  media  access  control  (MAC) 
frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete  type  of 
packet  body  as  shown  in  Figure  11-79. 
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Figure  1 1-79.  Ethernet  Data  Packet  Format  0  Channel-Specific  Data  Word 


•  Format.  Bits  31-28  indicate  the  type  of  Ethernet  packet. 

0000  =  Ethernet  physical  layer  IEEE  802.3  MAC  Frame 
000 1-1111  =  Reserved 

•  Time  Tag  Bits  (TTB).  Bits  27-25  indicate  which  bit  of  the  Ethernet  MAC  frame  the 
IPH  time  tag  is  applicable  to. 

000  =  First  bit  of  the  MAC  frame  MAC  destination  address 

001  =  Last  bit  of  the  MAC  frame  check  sequence 

010  =  First  bit  of  the  MAC  frame  payload  data 

011  =  Last  bit  of  the  MAC  frame  payload  data 

100-11 1  =  Reserved 

•  Reserved.  Bits  24-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
frames  included  in  the  packet. 

b.  Ethernet  Data  Packet  Format  0,  Intra-Packet  Header.  After  the  channel-specific  data, 
Ethernet  data  is  inserted  into  the  packet.  Each  frame  is  preceded  by  an  IPH  that  has  both 
an  IPTS  and  an  IPDH  containing  a  frame  ID  word.  The  length  of  the  IPH  is  fixed  at  12 
bytes  (96  bits)  positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure 
11-80. 
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Figure  11-80.  Ethernet  Data  Format  0  Intra-Packet  Header 


•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  frame  data.  First 
long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  TTBs  in  the  CSDW  of  the  frame  with 
bits  31  to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  data  bit 
indicated  in  the  TTBs  in  the  CSDW  of  the  frame. 


•  Frame  ID  Word.  The  frame  ID  word  is  an  identification  word  that  precedes  the 
Ethernet  frame  and  is  inserted  into  the  packet  with  the  format  shown  in  Figure  11-81. 
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Figure  1 1-81.  Intra-Packet  Frame  ID  Word 


o  Frame  CRC  Error  (FCE).  Bit  31,  the  frame  CRC  error  bit,  is  used  to  indicate 
that  a  MAC  frame  CRC  error  occurred  during  frame  transmission. 

0  =  No  frame  CRC  error 
1  =  Frame  CRC  error  encountered 

o  Frame  Error  (FE).  Bit  30,  the  frame  error  bit,  is  used  to  indicate  any  error  that 
occurred  during  frame  transmission. 

0  =  No  frame  error 
1  =  Frame  error  encountered 

o  Captured  Data  Content  (CONTENT).  Bits  29-28  specify  the  extent  of  the 
captured  MAC  frame. 

00  =  Full  MAC  frame:  starting  with  the  6-byte  destination  MAC  address 
and  ending  with  the  4-byte  frame  check  sequence. 

01  =  Payload  (data)  only:  starting  at  the  14th  byte  offset  from  the 

beginning  of  the  destination  MAC  address  and  ending  before  the  4- 
byte  frame  check  sequence  of  the  MAC  frame. 

10  =  Reserved  for  future  format. 

11=  Reserved  for  future  format. 

o  Ethernet  Speed  (SPEED).  Bits  27-24  indicate  the  negotiated  bit  rate  for  the 
identified  NETID  on  which  the  frame  was  captured. 

0000  =  Auto 
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0001  =  10  megabits  per  second  (Mbps) 

0010  =  100  Mbps 

001 1  =  1  gigabit  per  second  (Gbps) 

0100  =  10  Gbps 
0101  -1111  =  Reserved 

o  Network  Identifier  (NETID).  Bits  23-16  contain  a  binary  value  that  represents 
the  physical  network  identification  of  frame  origination  that  follows  the  ID 
word.  Zero  means  first  and/or  only  physical  network. 

o  Data  CRC  Error  (DCE).  Bit  15,  the  data  CRC  error  bit,  is  used  to  indicate  that 
a  CRC  error  exists  in  the  payload  of  the  frame. 

0  =  No  data  CRC  error 
1  =  Data  CRC  error  encountered 

o  Data  Length  Error  (LE).  Bit  14,  the  data  length  error  bit,  is  used  to  indicate 
that  the  frame  is  too  short  (less  than  64  bytes)  or  too  long  (longer  than  1518 
bytes). 

0  =  Valid  length 

1  =  Data  length  ID  too  short  or  too  long. 

o  Data  Length.  Bits  13-0  contain  a  binary  value  that  represents  the  length  of  the 
frame  in  bytes  ( n )  that  follows  the  ID  word. 

1 1.2. 15.2  Ethernet  Data  Packets,  Format  1,  ARINC-664 

Any  User  Datagram  Protocol  (UDP)  packets  from  Ethernet  and/or  ARINC-664  Part  7 
(referred  to  as  “ARINC-664”  in  this  standard)  network  interfaces  can  be  placed  into  an  Ethernet 
Data  Packet  Format  1  as  shown  in  Table  11-48. 


Table  11-48.  Ethernet  Data  Format  1 

msb  lsb 

15  0 

Packet  Header 

Channel-Specific  Data  (Bits  15-0) 

Channel-Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  15-0) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  31-16) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  47-32) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  63-48) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  79-64) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  95-80) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  111-96) 

Intra-Packet  Data  Header  for  Msg  1  (Bits  127-112) 
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Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Intra-Packet  Time  Stamp  for  Msg  N  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  N  (Bits  63-48) 
Intra-Packet  Data  Header  for  Msg  N  (Bits  15-0) 


Intra-Packet  Data  Header  for  Msg  N  (Bits  127-112) 


Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

The  ARINC-664  is  based  on  the  Ethernet  specification,  IEEE  Standard  802. 3-2012. 32 
Unlike  the  Ethernet  frame,  the  last  byte  of  a  frame  payload  is  used  for  the  frame  sequence 
number.  This  byte  is  located  just  before  the  MAC  CRC  field,  as  part  of  the  MAC  payload. 
Ethernet  Data  Packets,  Format  1  ARINC-664  shall  capture  and  store  the  entire  ARINC-664 
message  (the  entire  UDP  payload),  including  one  or  more  fragmented  frames. 

The  ARINC-664  frame  sequence  numbers  are  used  by  the  end  system  for  integrity 
checking  and  redundancy  management.  ARINC-664  requires  two  redundant  switch  networks. 
Each  ARINC-664  frame  is  replicated  and  sent  on  both  networks.  The  ARINC-664  receiving  end 
system  uses  the  sequence  number  to  check  for  dropped  frames  and  to  eliminate  redundant 
frames.  The  link  layer  of  the  receiver’s  ARINC-664  interface  discards  the  sequence  number  and 
drops  the  redundant  frame  before  passing  the  frame’s  payload  to  the  Internet  Protocol  (IP) 
network  layer  of  the  protocol  stack.  If  a  UDP  datagram  is  fragmented,  the  sequence  numbers  on 
the  fragments  are  discarded  prior  to  datagram  reassembly.  Table  11-49  compares  a  normal 
Ethernet  frame  with  an  ARINC-664  frame. 


Table  11-49.  Comparison  of  Normal  Ethernet  and  ARINC-664  Frames 

Normal  Ethernet 

Tame 

7  bytes 

1  byte 

14  bytes 

20  bytes 

8  bytes 

<  1472 
bytes 

4  bytes 

Preamble 

Start 

Delimiter 

MAC 

Header 

IP  Header 

UDP 

Header 

UDP 

Payload 

FCS  ! 

ARINC-664  Frame 

7  bytes 

1  byte  Mbytes  20  bytes  8  bytes  <1471  1  byte  4 bytes  ' 

bytes 

32  Institute  of  Electrical  and  Electronics  Engineers.  IEEE  Standard  for  Ethernet.  IEEE  802.3-2012.  New  York: 
Institute  of  Electrical  and  Electronics  Engineers. 
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Preamble 

Start 

MAC 

IP 

UDP 

ARINC- 

Sequence 

FCS 

Delimiter 

Header 

Header 

Header 

664 

Payload 

Number 

a.  Ethernet  Data  Format  1,  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
Ethernet  data  packet  begins  with  a  CSDW.  It  indicates  how  many  ARINC-664  messages 
are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete  type  of  packet 
body  as  shown  in  Figure  11-82. 
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Intra-Packet  Header  Fength 

Number  ofARINC-664  Messages 

Figure  11-82.  Ethernet  Data  Packet  Format  1  Channel-Specific  Data  Word 


•  Intra-Packet  Header  Fength.  Bits  31-16  contain  the  length  of  the  IPH  in  bytes;  this  is 
fixed  at  28. 

•  Number  of  Messages.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
messages  included  in  the  packet. 

b.  Ethernet  Data  Packet  Format  1  Intra-Packet  Header.  After  the  channel- specific  data, 
ARINC-664  data  is  inserted  into  the  packet.  Each  message  is  preceded  by  an  IPH  that 
has  both  an  IPTS  and  an  IPDH.  The  length  of  the  IPH  is  fixed  at  28  bytes  (224  bits) 
positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure  11-83. 

msb  lsb 

_31 _ 0_ 

Time  (FSFW) _ 

Time  (MSFW) _ 

Intra-Packet  Data  Header  1 
Intra-Packet  Data  Header  2 
Intra-Packet  Data  Header  3 
Intra-Packet  Data  Header  4 
Intra-Packet  Data  Header  5 

Figure  1 1-83.  Ethernet  Data  Format  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  ARINC-664 
message.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the 
following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit  in  the  frame  with  bits  31 
to  16  in  the  second  long  word  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  in  the  frame. 
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•  Intra-Packet  Data  Header.  These  20  bytes  contain  ARINC-664  message  data  length, 
virtual  link,  source  and  destination  IP  addresses,  and  source  and  destination  UDP 
ports,  as  shown  in  Figure  11-84. 
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Figure  11-84.  Intra-Packet  Data  Header 


o  Data  Length  (bits  31-16) 

Message  length  in  bytes 

o  ERROR  Bits  (bits  15-8) 

0:  No  errors 
1 :  Any  undefined  error 
2-15:  Reserved 

o  Flags  (bits  7-0) 

0:  Actual  ARINC-664  data 
1:  Simulation  ARINC-664  data 
2-15:  Reserved 

o  Reserved  (bits  31-16) 

o  Virtual  Link  (VL)  (bits  15-0) 

Lower  16  bits  of  the  Ethernet  destination  MAC  address 

o  Source  IP  address  (bits  31-0) 

Source  IP  address  from  ARINC-664  IP  header 

o  Pest  IP  Address  (bits  31-0) 

Destination  IP  address  from  ARINC-664  IP  header 

o  Src  Port  (bits  31-16) 

16  bits  source  port  from  the  ARINC-664  UDP  header 
o  Pest  Port  (bits  15-0) 

Destination  port  from  the  ARINC-664  UDP  header 

11.2.16  Time  Space  Position  Information  and  Combat  Training  Systems  Data  Packets 

The  Time  Space  Position  Information  (TSPI)  and  Combat  Training  Systems  (CTS)  data 
type  packets  are  provided  to  allow  a  defined  method  of  TS  PI/CTS  data  encapsulation  in  Chapter 
1 1  packet  format.  This  will  provide  interoperability  of  these  data  sets  between  ranges  and  users 
along  with  alignment  to  other  digital  data  in  the  recording,  such  as  video  and  audio. 


11-103 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


The  TSPI/CTS  data  packets  do  not  require  a  specific  input  interface  such  as  PCM, 
analog,  or  MIL-STD-1553.  The  TSPI/CTS  data  type  will  only  encapsulate  multiple  types  of 
TSPI/CTS  information  IAW  governing  standards  and  specifications.  Essentially,  TSPI/CTS  data 
will  be  wrapped  in  its  native  format  by  Chapter  1 1  packet  structures  and  reside  on  compliant 
media  devices  and/or  within  files.  The  packet  definition  will  not  characterize  transmission 
protocols  or  requirements  because  those  are  provided  by  the  governing  standards  or 
specifications. 

The  TSPI/CTS  packets  are  considered  dynamic  and  timing  requirements  (e.g.,  of  Chapter 
10)  apply  whether  they  are  generated  by  the  recorder/multiplexer,  like  computer-generated  data 
packets,  or  generated  via  a  specific  external  interface. 


11.2.16.1  TSPI/CTS  Data  Packets,  Format  0  (NMEA-RTCM) 

Any  GPS  data  as  defined  by  the  National  Marine  Electronics  Association  (NMEA)  and 
Radio  Technical  Commission  for  Maritime  Services  (RTCM)  standards  will  be  encapsulated  in 
the  Format  0  packet.  The  NMEA  and  RTCM  standards  specify  the  electrical  signal 
requirements,  data  transmission  protocol,  and  message/sentence  formats  for  GPS  data.  These 
formatting  standards  will  not  be  detailed  in  this  chapter,  but  they  will  be  referenced  as  required 
for  clarity. 

The  TSPI/CTS  Data  Packet,  Format  0  (NMEA-RTCM)  will  not  support  proprietary 
messages  or  sentences;  therefore,  any  data  containing  these  will  be  considered  non-compliant 
with  this  standard. 


A  packet  with  n  NMEA-RTCM  data  has  the  basic  structure  as  Table  11-50. 

Table  11-50.  NMEA-RTCM  Data  Packet  Format 


lsb 

_0 

Packet  Header _ 

Channel- Specific  Data  (Bits  15-0) 

Channel- Specific  Data  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  63-48) 

Intra-Packet  Data  Header  (Bits  15-0) 

Intra-Packet  Data  Header  (Bits  31-16) 

Byte  2  Byte  1 


Filler  (if  n  is  Odd) Byte  N 


(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  15-0) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  31-16) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  47-32) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  63-48) 
Intra-Packet  Data  Header  (Bits  15-0) 


msb 

15 
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Intra-Packet  Data  Header  (Bits  31-16) 

Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

a.  NMEA-RTCM  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each 
NMEA-RTCM  data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-85. 
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Figure  1 1-85.  NMEA-RTCM  Packet  Channel- Specific  Data  Word 


•  IPTS.  Bit  31  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  TYPE.  Bits  30-27  indicate  the  type  of  data  NMEA-RTCM  contains  within  the 
packet. 

0000  =  NMEA  0183 
0001  =  NMEA0183-HS 
0010  =  NMEA  2000 
0011  =  RTCM  SC  104 
0010  -  1111  =  Reserved 

•  RESERVED.  Bits  26-0  are  reserved  and  shall  be  zero-filled. 

b.  NMEA-RTCM  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before 
each  NMEA-RTCM  message.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned 
contiguously,  in  the  following  sequence  (Figure  1 1-86). 

msb  lsb 

_31 _ 0_ 

(Optional)  Time  (LSLW) _ 

(Optional)  Time  (MSLW) _ 

Figure  11-86.  NMEA-RTCM  Intra-Packet  Time  Stamp 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  NMEA-RTCM 
data.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSLW)  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit. 
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c.  NMEA-RTCM  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32 
bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-87). 
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LENGTH 

Figure  11-87.  NMEA-RTCM  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 

•  LENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 


1 1.2. 16.2  TSPI  Data  Packets,  Format  1  (EAG  ACMI) 

Air  Combat  Maneuvering  Instrumentation  (ACMI)  data  as  defined  by  the  European  Air 
Group  (EAG)  interface  control  document  (ICD)  DF2912533for  post-mission  interoperability  will 
be  encapsulated  in  the  Format  1  packet.  The  EAG  ACMI  ICD  defines  the  data  contents  and 
organization.  Electrical  signal  requirements  and  data  transmission  protocol  are  not  defined  in 
DF29125  or  in  this  Chapter  1 1  format.  The  data  type  will  be  8-bit  ASCII.  A  packet  of  EAG 
ACMI  data  has  the  basic  structure  of  Table  11-51. 


Table  11-51.  EAG  ACMI  Data  Packet  Format 


lsb 

_0 

Packet  Header 

_ Channel- Specific  Data  (Bits  15-0) _ 

_ Channel- Specific  Data  (Bits  31-16) _ 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  15-0) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp-Data  Block  1  (Bits  63-48) 

Intra-Packet  Data  Header 

(Optional)  Static  Data _ _ 

Byte  2  Byte  1 


Filler  (if  n  is  Odd) _  Byte  N 

Packet  Trailer 


msb 

15 


a.  EAG  ACMI  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  EAG 
ACMI  data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-88. 


33  European  Air  Group.  “European  Air  Group  Interface  Control  Document  for  Post  Mission  Interoperability.” 
DF29 125  Draft  A  Issue  01.  July  2004.  Retrieved  27  April  2017.  Available  to  RCC  members  with  Private  Portal 
access  at  https://wsdmext.wsmr. army. mil/site/rccpri/Limited  Distribution  References/DF29125.pdf. 
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msb 

lsb 

31 

30  29 

28 

0 

IPTS 

CONTENT 

RESERVED 

Figure  11-88.  EAG  ACMI  Packet  Channel-Specific  Data  Word 


•  IPTS.  Bit  31  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  CONTENT.  Bits  30-29  indicate  the  content  of  the  EAG  ACMI  data  within  the 
packet. 

00  =  TSPI  data  only  (no  static  data  or  pod  ID) 

01  =  Contains  pod  ID  and  static  data 
10  -  11  =  Reserved 

•  RESERVED.  Bits  28-0  are  reserved. 

b.  EAG  ACMI  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before  the 
EAG  ACMI  data  block.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned 
contiguously,  in  the  following  sequence  (Figure  11-89). 

msb  lsb 

_31 _ 0_ 

(Optional)  Time  (LSLW) _ 

(Optional)  Time  (MSLW) _ 

Figure  1 1-89.  EAG  ACMI  Data  Intra-Packet  Time  Stamp 

•  EAG  ACMI  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the 
EAG  ACMI  TSPI  data.  Pod  ID  and  static  data  will  not  be  time-tagged  but  will 
precede  the  TSPI  data  in  the  packet.  First  long  word  bits  31-0  and  second  long  word 
bits  31-0  indicate  the  following  values. 

o  The  48-bit  RTC  that  corresponds  to  the  first  TSPI  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSLW)  of  the  IPTS  will  be  zero-filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit. 

c.  EAG  ACMI  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32 
bits)  positioned  contiguously,  in  the  following  sequence  (Figure  11-90). 
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Figure  11-90.  EAG  ACMI  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 
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•  LENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 


1 1.2.16.3  TSPI  Data  Packets,  Format  2  (ACTTS) 

Air  Combat  Test  and  Training  System  (ACTTS)  data  as  defined  by  the  US  AF  ACTTS 
interface  specification  WMSP  98-01 34  will  be  encapsulated  in  the  Format  2  packet.  The  ACTTS 
interface  specification  defines  the  unique  signal  interface  requirements  for  the  air-to-air,  air-to- 
ground,  ground-to-air  data  links,  and  aircraft  information  subsystem  recording  formats.  The 
ACTTS  WMSP  98-01  establishes  the  requirements  for  the  information  recorded  on  the  different 
data  transfer  units  used  by  the  various  ACTTS  airborne  subsystems  to  support  both  tethered  and 
rangeless  operations. 


When  encapsulating  ACTTS  message/word  format,  data  messages  or  words  will  not  span 
packets.  Each  new  packet  will  start  with  a  full  message  and  not  a  partial  message  or  word.  A 
packet  of  ACTTS  data  has  the  basic  structure  of  Table  11-52. 


Table  11-52.  ACTTS  Data  Packet  Format 


msb  lsb 

15 _ 0 

Packet  Header _ 

_ Channel-Specific  Data  (Bits  15-0) _ 

_ Channel-Specific  Data  (Bits  31-16) _ 

_ (Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  15-0) _ 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  31-16) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  47-32) 

(Optional)  Intra-Packet  Time  Stamp  for  Data  1  (Bits  63-48) 


Intra-Packet  Data  Header 


Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  15-0) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  31-16) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  47-32) 
(Optional)  Intra-Packet  Time  Stamp  for  Data  N  (Bits  63-48) 


Intra-Packet  Data  Header 


Byte  2 

Byte  1 

Filler  (if  n  is  Odd) 

Byte  N 

Packet  Trailer 

34  Range  Instrumentation  System  Program  Office,  Air  Armament  Center.  “Interface  Specification  for  the  USAF  Air 
Combat  Test  and  Training  System  (ACTTS)  Air-to-Ground,  Air-to-Air,  Ground-to-Air  Data  Links,  and  AIS 
Recording  Formats."  WMSP  98-01,  Rev  A,  Chg  1.  19  May  2003.  Retrieved  27  April  2017.  Available  to  RCC 
members  with  Private  Portal  access  at 

https://wsdmext.wsmr.army. mil/site/rccpri/Limited  Distribution  References/WMSP  98-01. doc. 


11-108 


Telemetry  Standards,  IRIG  Standard  106-17  Chapter  11,  July  2017 


a.  ACTTS  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  ACTTS 
data  packet  begins  with  a  CSDW  as  shown  in  Figure  11-91. 
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IPTS 

FORMAT 

RESERVED 

Figure  1 1-91.  ACTTS  Packet  Channel-Specific  Data  Word 


•  IPTS.  Bit  31  indicates  whether  the  IPTS  is  enabled. 

0  =  IPTS  not  enabled 
1  =  IPTS  enabled 

•  FORMAT.  Bits  30-27  indicate  the  ACTTS  format  type  of  data  contained  within  the 
packet. 

0000  =  Kadena  Interim  Training  System  (KITS)  Recording  Formats 
0001  =  Alpena  KITS  Recording  Formats 

0010  =  USAF  Europe  Rangeless  Interim  Training  System  Recording  Formats 
0011  =  Alaska  ACTS  Upgrade  Recording  Formats 

0100  =  Goldwater  Range  Mission  and  Debriefing  System  Recording  Formats 
0101  =  P4RC  Recording  Formats 

0110  =  Nellis  ACTS  Range  Security  Initiative  Recording  Formats 
0111  =  P4RC+P5  CTS  Participant  Subsystem  Recording  Formats 

1000  =  P5  CTS  Recording  Formats 

1001  -1111  =  Reserved 

•  RESERVED.  Bits  26-0  are  reserved. 

b.  ACTTS  Intra-Packet  Time  Stamp.  If  enabled  the  optional  IPTS  is  inserted  before  each 
ACTTS  message.  The  length  of  the  IPTS  is  8  bytes  (64  bits)  positioned  contiguously,  in 
the  following  sequence  (Figure  11-92). 

msb  lsb 

_31 _ 0_ 

(Optional)  Time  (LSLW) _ 

(Optional)  Time  (MSLW) _ 

Figure  1 1-92.  ACTTS  Data  Intra-Packet  Time  Stamp 

These  8  bytes  indicate  the  time  tag  of  the  ACTTS  data.  First  long  word  bits  31-0  and 
second  long  word  bits  31-0  indicate  the  following  values. 

•  The  48-bit  RTC  that  corresponds  to  the  first  ACTTS  data  bit.  Bits  31  to  16  in  the 
second  long  word  (MSLW)  of  the  IPTS  will  be  zero-filled;  or 

•  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1  item  g). 
The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  tag  shall  be  correlated  to  the  first  data  bit. 

c.  ACTTS  Intra-Packet  Data  Header.  The  length  of  the  IPDH  is  fixed  at  4  bytes  (32  bits) 
positioned  contiguously,  in  the  following  sequence  (Figure  11-93). 
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RESERVED 

LENGTH 

Figure  1 1-93.  ACTTS  Data  Intra-Packet  Data  Header 


•  RESERVED.  Bits  31-16  are  reserved. 

•  LENGTH.  Bits  15-0  indicate  the  length  of  the  message  in  bytes. 
11.2.17  Controller  Area  Network  Bus  Packets 


1 1.2.17.1  Controller  Area  Network  Bus  Data  Packet,  Format  0 

Data  from  one  or  more  controller  area  network  (CAN)  bus  interfaces  are  placed  into  a 
CAN  bus  data  packet  format  as  shown  in  Table  11-53. 


Table  11-53.  Controller  Area  Network  Bus  Data  Packet,  Format  0 

msb  lsb 

_L5 _ 0 

Packet  Header _ 

Channel- Specific  Data  (Bits  15-0) 

Channel- Specific  Data  (Bits  31-16) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  15-0) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  47-32) 

Intra-Packet  Time  Stamp  for  Msg  1  (Bits  63-48) 

Intra-Packet  Message  Header  for  Msg  1  (Bits  15-0) _ 

Intra-Packet  Message  Header  for  Msg  1  (Bits  31-16) _ 

Intra-Packet  ID  Word  for  Msg  1  (Bits  47-32) 


Intra-Packet  ID  Word  for  Msg  1  (Bits  63-48) 


Msg  1  Byte  2 

Msg  1  Byte  1 

Filler  (if  n  is  Odd) 

Msg  1  Byte  n 

Intra-Packet  Time  Stamp  for  Msg  n  (Bits  15-0) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  31-16) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  47-32) 
Intra-Packet  Time  Stamp  for  Msg  n  (Bits  63-48) 
Intra-Packet  Message  Header  for  Msg  n  (Bits  15-0) 
Intra-Packet  Message  Header  for  Msg  n  (Bits  31-16) 
Intra-Packet  ID  Word  for  Msg  n  (Bits  47-32) 


Intra-Packet  ID  Word  for  Msg  n  (Bits  63-48) 


Msg  n  Byte  2 

Msg  n  Byte  1 

Filler  (if  m  is  odd) 

Msg  n  Byte  m 

Packet  Trailer 
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a.  CAN  Bus  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of  each  CAN 
bus  data  packet  begins  with  a  CSDW.  Figure  11-94  displays  a  complete  CAN  bus 
CSDW. 
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31 

16 

15 

0 

RESERVED 

N  of  Messages 

Figure  1 1-94.  Complete  CAN  Bus  Format  0  Channel-Specific  Data  Word 


•  Reserved.  Bits  31-16  are  reserved. 

•  N  of  Messages.  Bits  15-0  contain  a  binary  value  indicating  the  number  of  messages 
included  in  the  packet. 

b.  CAN  Bus  Data  Intra-Packet  Header.  After  the  CSDW,  CAN  bus  data  is  inserted  into  the 
packet.  Each  CAN  bus  message  is  preceded  by  an  IPH  that  has  both  an  IPTS  and  an 
intra-packet  message  header  (IPMH)  and  an  intra-packet  ID  word.  The  length  of  the  IPH 
is  fixed  at  16  bytes  (128  bits)  positioned  contiguously,  in  the  sequence  shown  in  Figure 
11-95. 

msb 

_31 _ 

Intra-Packet  Time  Stamp  (LSLW) 

Intra-Packet  Time  Stamp  (MSLW) 

Intra-Packet  Message  Header 
Intra-Packet  ID  Word 
Figure  1 1-95.  CAN  Bus  Data  Format  0  Intra-Packet  Data  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  message  data. 
First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate  the  following 
values. 

o  The  RTC  that  corresponds  to  the  first  data  bit  in  the  message  with  bits  31  to 
16  in  the  second  long  word  zero-filled;  or 

o  Time,  if  enabled  by  bit  7  in  the  packet  flags.  Time  format  is  indicated  by  bits 
2  and  3  in  the  packet  flags  and  to  the  first  data  bit  in  the  message. 


•  Intra-Packet  Message  Header.  The  IPMH  is  an  information  word  that  is  inserted  into 
the  packet  with  the  format  shown  in  Figure  11-96. 
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3  0 

DE 

FE 

Reserved 

SUBCHANNEL 

Reserved 

MESSAGE  LENGTH 

Figure  11-96.  Intra-Packet  Message  Header 


o  Data  Error  (DE).  Bit  31  indicates  bad  data  bits  as  determined  by  parity, 
checksums,  or  CRC  words  received  with  the  data. 

0  =  No  data  error  has  occurred 


lsb 

0 
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1  =  Data  error  has  occurred 

o  Format  Error  (FE).  Bit  30  indicates  a  protocol  error,  such  as  out-of- sequence 
data  or  length  errors. 

0  =  No  format  error 
1  =  Format  error  encountered 

o  Reserved.  Bits  29-24  are  reserved. 

o  Subchannel.  Bits  23-16  contain  a  binary  value  that  represents  the  subchannel 
number  belonging  to  the  message  that  follows  the  ID  word  when  the  channel 
ID  in  the  packet  header  defines  a  group  of  subchannels.  Zero  means  first 
and/or  only  subchannel,  which  is  valid  for  the  CAN  bus. 

o  Reserved.  Bits  15-4  are  reserved. 

o  Message  Length.  Bits  3-0  contain  a  binary  value  representing  the  length  of 
the  number  of  the  valid  bytes  in  the  rest  of  the  message  that  follows  the 
IPMH.  The  message  length  will  be  4-12  bytes  (4  bytes  for  the  intra-packet  ID 
word  +  0-8  bytes  data  content  of  the  CAN  bus  message). 

•  Intra-Packet  ID  Word.  The  intra-packet  ID  word  contains  the  CAN  bus  message  ID 
word  transmitted  on  the  bus.  This  word  precedes  the  message  and  is  inserted  into  the 
packet  with  the  format  shown  in  Figure  11-97. 
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31 

30 
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28 
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IDE 

RTR 

Res 

CAN  Bus  ID 

Figure  1 1-97.  Intra-Packet  ID  Word 


o  IDE  (bit  31  of  the  32-bit  CAN  ID  word):  use  extended  CAN  identifier. 

0  =  11 -bit  standard  CAN  identifier  (CAN  ID  word  bits  10-0) 

1  =  29-bit  extended  CAN  identifier  (CAN  ID  word  bits  28-0) 

o  RTR  (bit  30  of  the  CAN  ID  word):  Remote  transfer  request  bit. 

o  CAN  Bus  ID:  The  CAN  bus  ID  transmitted  in  the  message. 

When  using  the  11 -bit  standard  CAN  identifier,  bits  29-11  of  the  32-bit  CAN 
ID  word  are  unused.  For  the  29-bit  extended  CAN  identifier  all  the  29  bits, 
28-0,  are  used. 

•  CAN  Bus  Message.  The  CAN  bus  message  is  placed  behind  the  CAN  bus  IPH.  The 
message  can  consist  up  to  8  bytes,  which  is  placed  in  0-4  x  16-bit  data  words.  Figure 
11-98  displays  a  CAN  bus  message  format. 


BYTE  2 

BYTE  1 

Filler  (if  n  is  Odd) 

BYTE  n 

hgure  11-98.  CAN  Bus  Format  0  Message 
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1 1 .2. 17.2  Controller  Area  Network  Bus  Data  Packet,  Format  1 
This  section  is  reserved  for  future  development 

11.2.18  Fibre  Channel  Packets 


11.2.18.1  Fibre  Channel  Data  Packets,  Format  0  (FC-PH  Layer) 

Data  from  a  Fibre  Channel  port  can  be  placed  into  a  Fibre  Channel  Data  Packet  Format  0 
as  shown  in  Table  11-54. 


Table  11-54.  Fibre  Channel  Data  Packet,  Format  0 

msb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  15-0) _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FILLER  (IF  n  IS  ODD) 

FRAME  BYTE  n 

INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FILLER  (IF  n  IS  ODD) 

FRAME  BYTE  n 

PACKET  TRAILER 


a.  Fibre  Channel  Data  Packet  Channel- Specific  Data  Word.  The  packet  body  portion  of 
each  Fibre  Channel  data  packet  begins  with  a  CSDW.  It  indicates  the  format  and  how 
many  Fibre  Channel  frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for 
the  complete  type  of  packet  body  as  shown  in  Figure  11-99. 
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Figure  1 1-99.  Fibre  Channel  Data  Packet  Channel-Specific  Data  Word 
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•  Format.  Bits  31-28  indicate  the  type  of  Fibre  Channel  data  packet. 

0000  =  FC-PH  physical  layer  ANSI  X3T11  Project  755-D 
0001  -  1 1 1 1  =  Reserved 

•  Reserved.  Bits  27-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
complete  or  stripped  Fibre  Channel  frames  included  in  the  packet. 

b.  Fibre  Channel  Data  Packet  Format  0  Intra-Packet  Header.  After  the  channel-specific 
data,  complete  or  stripped  Fibre  Channel  frames  are  inserted  into  the  packet.  Each 
complete  or  stripped  Fibre  Channel  frame  is  preceded  by  an  IPH  that  has  both  an  IPTS 
and  an  IPDH  containing  a  frame  ID  word.  The  length  of  the  IPH  is  fixed  at  12  bytes  (96 
bits)  positioned  contiguously,  in  the  following  sequence  as  shown  in  Figure  11-100. 
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_31 _ 0_ 

TIME  (LSLW) _ 

TIME  (MSLW) _ 

FRAME  ID  WORD _ 

Figure  1 1-100.  Fibre  Channel  Data  Format  0  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  complete  or 
stripped  Fibre  Channel  frame.  First  long  word  bits  31-0  and  second  long  word  bits 
31-0  indicate  the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  bit  after  the  CSDW  of  the 
complete  or  stripped  Fibre  Channel  frame  with  bits  31  to  16  in  the  second 
long  word  zero  filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  The  time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g).  The  time  tag  shall  be  correlated  to  the  first  data 
bit  of  the  complete  or  stripped  Fibre  Channel  frame. 


•  Frame  ID  Word.  The  frame  ID  word  is  an  identification  word  that  precedes  the  Fibre 
Channel  frame  and  is  inserted  into  the  packet  with  the  format  shown  in  Figure 
11-101. 
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Figure  11-101.  Fibre  Channel  Data  Format  0  Intra-Packet  Frame  ID  Word 


o  Framing  Error  (FE).  Bit  31  indicates  a  framing  error  such  as  EOF  missing. 
0  =  No  framing  error. 

1  =  Framing  error  detected  in  Fibre  Channel  frame, 
o  CRC  Error  (CE).  Bit  30  indicates  a  CRC  error. 

0  =  No  CRC  error. 
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1  =  CRC  error  detected  in  Fibre  Channel  frame, 
o  Overrun  Error  (OE).  Bit  29  indicates  a  buffer  overrun  error. 

0  =  No  overrun  error. 

1  =  Overrun  error  detected  prior  to  this  Fibre  Channel  frame. 

o  Stripped  Mode  (SM).  Bit  28  indicates  whether  the  Fibre  Channel  frame 
delimiters,  header,  and  CRC  are  removed,  resulting  in  a  stripped  Fibre 
Channel  frame  with  data  payload  only. 

0=  Stripped  mode.  Only  Fibre  Channel  data  payload  is  present. 

1=  Non-stripped  mode.  Complete  Fibre  Channel  frame  is  present. 

o  Content  (CONTENT).  Bits  27-26  specify  the  type  of  the  Fibre  Channel 
frame.  Content  bits  are  only  valid  when  in  non-stripped  mode  (i.e.,  bit  28  = 

1). 

00  =  Complete  data  frame 

01  =  Complete  link  control  frame 

10-11  =  Reserved 

o  Topology  (TOP).  Bits  25-24  specify  the  Fibre  Channel  topology  of  frame 
from  the  port. 

00  =  Passive 
01-11  Reserved 

o  Reserved.  Bits  23-19  are  reserved. 

o  End  of  Frame  (EOF).  Bits  18-16  indicate  a  binary  value  for  the  end-of-frame 
delimiter  that  terminated  the  Fibre  Channel  frame.  This  is  applicable  only  in 
stripped  mode.  Values  are  as  follows: 

000  -  (0):  EOF  normal  (EOFn) 

001  -  (1):  EOF  terminate  (EOFt) 

010  -  (2):  EOF  disconnect  terminate  (EOFdt) 

011 -(3):  EOF  abort  (EOFa) 

100  -  (4):  EOF  normal  invalid  (EOFni) 

101  -  (5):  EOF  disconnect  terminate  Invalid  (EOFdti) 

1 10  -  (6):  EOF  remove  terminate  (EOFrt) 

1 1 1  -  (7):  EOF  remove  terminate  invalid  (EOFrti) 

o  Start  of  Frame  (SOF).  Bits  15-12  indicate  a  binary  value  for  the  start-of-frame 
delimiter  that  began  the  Fibre  Channel  frame.  This  is  applicable  only  in 
stripped  mode.  Values  are  as  follows: 

0000  -  (0):  SOF  connect  class-1  (SOFcl) 

0001  -  (1):  SOF  initiate  class-1  (SOFil) 

0010  -  (2):  SOF  normal  class-1  (SOFnl) 

0011  -  (3):  SOF  initiate  class-2  (SOFi2) 

0100  -  (4):  SOF  normal  class-2  (SOFn2) 

0101  -  (5):  SOF  initiate  class-3  (SOFi3) 

0110  -  (6):  SOF  normal  class-3  (SOFn3) 
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0111  -  (7):  SOF  activate  class-4  (SOFc4) 

1000  -  (8):  SOF  initiate  class-4  (SOFi4) 

1001  -  (9):  SOF  normal  class-4  (SOFn4) 

1010  -  (A):  SOF  fabric  (SOFf) 

1011  -  llll(B-F):  Reserved 

o  Frame  Length.  In  stripped  mode,  bits  11-0  indicate  the  length  of  the  frame’s 
data  payload  in  bytes  (excluding  the  SOF  and  EOF  delimiters  and  CRC  word). 
In  stripped  mode,  maximum  length  is  21 12  bytes.  In  non-stripped  mode,  bits 
1 1-0  indicate  the  length  of  the  entire  Fibre  Channel  frame  in  bytes.  The  frame 
length  must  be  divisible  by  4. 


11.2.18.2  Fibre  Channel  Data  Packets,  Format  1  (FC-FS  Layer) 

Data  from  a  Fibre  Channel  port  can  be  placed  into  a  Fibre  Channel  Data  Packet  Format  1. 
In  this  format,  the  Fibre  Channel  frames  placed  in  the  packet  include  only  the  frame  header  and 
data  field.  The  Start-of-Frame  delimiter,  End-of-Frame  delimiter,  and  CRC  word  of  the  frame 
are  excluded.  Fibre  Channel  Data  Packet  Format  1  is  shown  in  Table  11-55. 


Table  11-55.  Fibre  Channel  Data  Packet,  Format  1 


msb  lsb 

15 _ 0 

_ PACKET  HEADER _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  15-0) _ 

_ CHANNEL-SPECIFIC  DATA  (BITS  31-16) _ 

INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  1  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FRAME  BYTE  n 

FRAME  BYTE  n-1 

INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  15-0) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  31-16) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  47-32) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  63-48) 
INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  79-64) 


INTRA-PACKET  HEADER  FOR  FIBRE  CHANNEL  FRAME  n  (BITS  95-80) 


FRAME  BYTE  2 

FRAME  BYTE  1 

: 

: 

FRAME  BYTE  n 

FRAME  BYTE  n-1 

PACKET  TRAILER 
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a.  Fibre  Channel  Data  Packet  Channel-Specific  Data  Word.  The  packet  body  portion  of 
each  Fibre  Channel  Data  Packet  begins  with  a  CSDW.  It  indicates  how  many  Fibre 
Channel  frames  are  placed  in  the  packet  body.  The  CSDW  is  formatted  for  the  complete 
type  of  packet  body  as  shown  in  Figure  11-102. 


msb 

lsb 

31 

16 

15 

0 

RESERVED 

NUMBER  OF  FRAMES 

Figure  1 1-102.  Fibre  Channel  Data  Packet  Channel-Specific  Data  Word 


Format 

•  Reserved.  Bits  31-16  are  reserved. 

•  Number  of  Frames.  Bits  15-0  contain  a  binary  value  that  represents  the  number  of 
Fibre  Channel  frames  included  in  the  packet. 

b.  Fibre  Channel  Data  Packet  Format  1  Intra-Packet  Header.  After  the  channel-specific 
data,  Fibre  Channel  frames  are  inserted  into  the  packet.  Each  Fibre  Channel  frame  is 
preceded  by  an  IPH  that  has  both  an  IPTS  and  an  IPDH  containing  a  frame  status  word. 
The  length  of  the  IPH  is  fixed  at  12  bytes  (96  bits)  positioned  contiguously,  in  the 
following  sequence  as  shown  in  Figure  11-103. 

msb  lsb 

_31 _ 0_ 

TIME  (LSLW) _ 

TIME  (MSLW) _ 

FRAME  STATUS  WORD _ 

Figure  11-103.  Fibre  Channel  Data  Format  1  Intra-Packet  Header 

•  Intra-Packet  Time  Stamp.  These  8  bytes  indicate  the  time  tag  of  the  Fibre  Channel 
frame.  The  timestamp  is  sampled  and  latched  at  the  end  of  the  last  bit  of  the  Start-of- 
Frame  delimiter.  First  long  word  bits  31-0  and  second  long  word  bits  31-0  indicate 
the  following  values: 

o  The  48-bit  RTC  that  corresponds  to  the  first  bit  after  the  CSDW  of  the  Fibre 
Channel  frame  with  bits  31  to  16  in  the  second  long  word  zero  filled;  or 

o  The  absolute  time,  if  enabled  by  bit  6  in  the  packet  flags  (Subsection  11.2.1.1 
item  g).  Time  format  is  indicated  by  bits  2  and  3  in  the  packet  flags 
(Subsection  11.2.1.1  item  g). 

•  Frame  Status  Word.  The  frame  status  word  precedes  the  Fibre  Channel  frame  and  is 
inserted  into  the  packet  with  the  format  shown  in  Figure  11-104. 


msb 

lsb 

31  30  29  28  19  18  16  15  12  11  0 

FE 

CE 

OE 

RESERVED 

EOF 

SOF 

FRAME  FENGTH 

Figure  11-104.  Fibre  Channel  Data  Format  1,  (FC-FS  Fayer)  Intra-Packet 


Frame  Status  Word 
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o  Framing  Error  (FE).  Bit  31  is  used  to  indicate  a  framing  error,  such  as  EOF 
missing. 

0  =  No  framing  error. 

1  =  Framing  error  detected  in  Fibre  Channel  frame, 
o  CRC  Error  (CE).  Bit  30  indicates  a  CRC  error  was  detected. 

0  =  No  CRC  error. 

1  =  CRC  error  detected  in  Fibre  Channel  frame, 
o  Overrun  Error  (OE).  Bit  29  is  used  to  indicate  a  buffer  overrun  error. 

0  =  No  overrun  error. 

1  =  Overrun  error  detected  prior  to  this  Fibre  Channel  frame, 
o  Reserved.  Bits  28-19  are  reserved. 

o  End  of  Frame  (EOF).  Bits  18-16  indicate  a  binary  value  for  the  End-Of- 
Frame  delimiter  that  terminated  the  Fibre  Channel  frame.  Values  are  as 
follows: 

000  -  (0):  EOF  normal  (EOFn) 

001  -  (1):  EOF  terminate  (EOFt) 

010  -  (2):  EOF  disconnect  terminate  (EOFdt) 

01 1  -  (3):  EOF  abort  (EOFa) 

100  -  (4):  EOF  normal  invalid  (EOFni) 

101  -  (5):  EOF  disconnect  terminate  invalid  (EOFdti) 

1 10  -  (6):  EOF  remove  terminate  (EOFrt) 

1 1 1  -  (7):  EOF  remove  terminate  invalid  (EOFrti) 

o  Start  of  Frame  (SOF).  Bits  15-12  indicate  a  binary  value  for  the  Start-Of- 
Frame  delimiter  that  began  the  Fibre  Channel  frame.  Values  are  as  follows: 

0000  -  (0):  SOF  connect  class-1  (SOFcl) 

0001  -  (1):  SOF  initiate  class- 1  (SOFil) 

0010  -  (2):  SOF  normal  class-1  (SOFnl) 

001 1  -  (3):  SOF  initiate  class-2  (SOFi2) 

0100  -  (4):  SOF  normal  class-2  (SOFn2) 

0101  -  (5):  SOF  initiate  class-3  (SOFi3) 

0110  -  (6):  SOF  normal  class-3  (SOFn3) 

0111  -  (7):  SOF  activate  class-4  (SOFc4) 

1000  -  (8):  SOF  initiate  class-4  (SOFi4) 

1001  -  (9):  SOF  normal  class-4  (SOFn4) 

1010  -  (A):  SOF  fabric  (SOFf) 

1011  -  llll(B-F):  Reserved 

o  Frame  Fength.  Bits  11-0  indicate  the  combined  length  of  the  Fibre  Channel 
frame  header  and  data  fields  (excludes  the  SOF,  EOF  delimiters,  and  CRC 
word  of  the  frame)  in  bytes.  This  field  must  be  evenly  divisible  by  4. 
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APPENDIX  11-A 
Definitions 

The  following  are  definitions  that  are  used  in  this  standard  and  are  provided  as  a  means  of 

removing  ambiguities  within  the  standard. 

Absolute  Time:  A  hypothetical  time  that  either  runs  at  the  same  rate  for  all  the  observers  in  the 
universe  or  the  rate  of  time  each  observer  can  be  scaled  to  by  multiplying  the  observer’s 
rate  by  a  constant. 

Byte:  A  contiguous  set  of  8  bits  that  are  acted  on  as  a  unit. 

Channel-Specific  Data  Word:  A  required  word  for  each  data  type  channel  that  has  data- specific 
information. 

Data  Streaming:  Streaming  of  current  value  data  whether  it  is  being  recorded  or  not,  and 

playback  streaming  of  recorded  data  from  a  file.  Data  streaming  sends  the  data  to  one  or 
more  destinations  simultaneously  (e.g.,  recording  media,  recorder  data  interfaces). 

Extended  Relative  Time  Counter:  A  1-GHz  extension  to  the  existing  10-MHz  RTC. 

Long  Word:  A  contiguous  set  of  32  bits  that  are  acted  on  as  a  unit. 

Mandatory:  Defines  a  mandatory  requirement  of  this  standard  for  full  compliancy.  Mandatory 
requirements  as  defined  in  this  standard  are  based  on  the  use  of  “shall”. 

Multiplexer:  The  entity  that  includes  all  the  inputs,  control  interfaces,  and  functionality  required 
to  properly  record  data. 

Packet:  Encapsulates  a  block  of  observational  and  ancillary  application  data  to  be  recorded. 

Packet  Generation:  The  placing  of  observational  and  ancillary  data  into  a  packet. 

Recorder:  Is  used  where  a  function  or  requirement  shall  apply  to  both  an  on-board  recorder  and 
a  ground-based  recorder. 

Recording:  Is  defined  as  the  time  interval  from  first  packet  generated  to  the  last  packet 

committed  to  the  recorder  media.  Packet  generation  time  and  stream  commit  time,  as 
defined  within  the  standard,  apply. 

Session:  Period  of  time  during  which  data  is  acquired,  processed  and/or  stored.  Typically 
corresponds  to  a  recording  (q.v.) 

Setup  Record:  TMATS  IAW  Chapter  9  annotated  in  the  Computer-Generated  Data,  Format  0 
packet. 

Stream:  All  packets  from  all  enabled  channels  (including  computer-generated  data)  that  are 
generated. 

Stream  Commit  Time:  The  time  span  in  which  all  generated  packets  must  be  committed  to  a 
stream. 

Word:  A  contiguous  set  of  16  bits  acted  on  as  a  unit. 
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